If you’ve worked on a digital product, whether as a developer, product manager, or business leader, you know that the most common problems in software development are rarely as straightforward as “bugs.” The root of the problem tends to require a little more trial and error. Using Courier is no different. In this post, we will discuss example issues around Courier’s Gmail integration and API rate limits, an incomplete data profile, and an incomplete request with Inbox and Toast. We will delve into how such issues can present themselves and how to troubleshoot independently to fix any issues. Troubleshooting through trial and error Just because an issue is complicated doesn’t mean the solution can’t be simple. Developers are constantly bombarded with jargon and terminology that could frighten even those of us who are more technologically-literate. Despite one’s development experience, programmers have learned how to find solutions through trial and error, pattern matching, and dare I say it - googling. Needless to say, it’s almost seen as a rite of passage in one’s programming journey. In this post, we’re going to tackle some of the most common, yet crucial hiccups our developers and users come across when integrating Courier into their notification infrastructure. If you’ve come across a hurdle, there’s a good chance that someone else has already figured out how to get across. Gmail integration and API rate limits Congratulations, you’ve successfully signed up to use Courier and are on your way to sending notifications! Once you’ve gone through the sign-up process and authorized Gmail to send emails on your behalf, you’ll be able to integrate Gmail as a channel to your email notification templates. The issue One recurring issue that has come up with our developers is getting rate limited, i.e when sending bulk transactional emails with Gmail integration. It’s understandable, getting 400 response errors isn’t fun. However as developers, Google-fu is one of the many skills required in troubleshooting. 429 errors The fix There’s no workaround here. Gmail's API has based on per-method quota usage (250 per second with 100 quota points per SEND). Thus, Gmail is really intended for getting started fast, testing, or small-scale sending. This is a great way for you to get comfortable with using Courier and make your first couple of sends. limitations Our recommendation is to check out of email providers and choose the best one that will suit your needs depending on your use case. If your intention is to send bulk emails at once, it would be best to choose a provider that will not rate limit you. our full list Incomplete profile data It goes without saying - Courier has an extensive list of notification providers our users can integrate into their notification infrastructure. Each of these providers have their own requirements for the profile object in the response. Without a profile in the request, some of your notifications will not be delivered and tell you why in the response that can be accessed from the message logs. The issue You’ve integrated your provider and set a channel to your notification. However, the message logs show an ‘Unroutable’ / ‘MISSING_PROVIDER_SUPPORT’ error in the response. This is strange, since you’ve integrated a provider, created a template, and sent a test event. The fix This varies by provider and channel, but for some of our most common integrations, i.e - email, the fastest fix to the “unroutable” error is by adding an email recipient to the profile. Courier supports many providers, and you can find each providers’ profile requirements in their respective . Depending on whether you’re using email, sms, push, etc to send your notifications, you want to make sure to provide a profile that matches the channel’s needs. integration documentation In-app notifications require a more detailed profile in the request which will be touched on in the following section. Profile exceptions For argument’s sake, let’s say you’ve integrated to send out notifications for your system alerts. In this case, Pagerduty does not require a profile because an event is mapped to Pagerduty services and not to an individual. So in this case, you can leave the profile empty. Pagerduty Courier Inbox and Toast incomplete request So you’ve decided you wanted a more centralized feed of your notifications and implemented Courier’s Inbox feature in your application. Our certainly makes it look good, and with the additional to match the look of your app and brand, how can one resist. And for our developers using non-react builds, we have for you. demo app customization options embedded integration The issue Let’s say you’ve successfully implemented Courier Inbox and Toast in your frontend with the right dependencies, and both Toast and Inbox are children of the in your application. CourierProvider component Everything looks as it should, and even provided a clientKey as a prop. After being able to send a request and receive no errors in our logs, we see a toast notification pop up in our app, yet if we navigate to our inbox widget, it’s empty. The fix Before we dive into the answer, let’s take a look at a sample send request in this case. In order for inbox notifications to persist, we need to add to.user_id in the SEND request along with to.courier.channel. This is for two reasons: to.user_id is used by Inbox to persist notifications. to.courier.channel is used by Toast to display your notifications. Your request/test event should now look like this: message: {
  to: {   
    user_id: “user_id”, 
  courier: {
    channel: “user_id”,  
} Once our SEND request includes the above configuration, your inbox messages will persist. Side note on dependencies/packages Our team at Courier is constantly working on making improvements, adding support for new features, and fixing bugs. This includes npm/yarn for CourierProvider, Toast, and Inbox. packages If you wish to update your dependencies, you can update them simply by changing the package.json to the most current version, and running yarn/npm from the root of your project. We invite you to reach out to support should you have any other questions or if you feel like you hit a roadblock. Still have questions? It’s the nature of the business to always be asking questions particularly in our line of work. This article is merely designed to help answer some of the most common questions we’ve come across with our developers. With that said, we believe that in order to make software-to-human communication delightful, there needs to be an open line of communication with developers who have implemented Courier to handle their notification infrastructure. We want you to have as many support options as possible whether it’s self-serve through our and , or 1-1 with our engineers and support staff. We’re here to make your Courier experience as smooth as possible! If you’d prefer enterprise-level support, sign up for a now! docs articles demo request

Google

Building a Slack Integration for Your SaaS Notification System

Courier's Journey to Becoming HIPAA-Compliant

Orchestrate Unlimited Notifications From 1 API | Sign-up today!

Common Courier Troubleshooting Solutions for Developers

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

3 Types Of User Communication APIs and When To Use Them

10 Must Have Chrome Extensions for a Web Developer

The Noonification: Can Mankind Survive as an Interplanetary Species? (10/20/2022)

132 Stories To Learn About Performance

3 Golang Pitfalls Every Developer Needs to Know

3 Types Of User Communication APIs and When To Use Them

10 Must Have Chrome Extensions for a Web Developer

The Noonification: Can Mankind Survive as an Interplanetary Species? (10/20/2022)

132 Stories To Learn About Performance

3 Golang Pitfalls Every Developer Needs to Know

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps