How Nylas Outbox Automatically Handles Email API Send Errors

How Nylas Outbox Automatically Handles Email API Send Errors

6 min read
Tags:

Nylas has expanded our Email API with the launch of our Outbox endpoint beta that makes it much easier for developers to send emails from their user’s email inbox. It’s the next big step for Nylas on our journey to build lean-code solutions for communications and scheduling integrations. Perhaps the most underrated feature is the new automatic error handling Nylas provides when sending emails. It represents a significant quality-of-life improvement for developers who build with Nylas.

If you want to build an integration with external APIs, you need to anticipate all of the ways requests to that integration can go wrong. Even a simple task like sending an email can fail in various ways, some of which are very specific to the job and the email provider. To complicate things further, every email provider has unique usage limitations, restrictions, and associated errors. 

The Lean-Code Solution to Common Email API Send Errors

Wouldn’t it be great if those could be abstracted away, enabling you to focus more on user functionality than back-end API error handling? This abstraction is precisely what the Nylas Outbox endpoint handles for you. For example, if you make a POST request to the Outbox endpoint to send an email:

curl -X POST 'https://api.nylas.com/outbox' \
-H 'Authorization: Bearer ACCESS_TOKEN' \
-d '{
  "send_at": 1008720000,
  "subject": "One Email API to rule them all",
  "body": "Keep it secret, keep it safe... or share it with your friends.",
  "to": [{
          "email": "[email protected]",
          "name": "Frodo Baggins"
  }]  
}'

Nylas will make sure the email gets sent, even if we encounter common third-party API errors. What does this mean exactly? Let’s take a deeper dive into the errors that APIs for email providers like Gmail, Exchange, Outlook, and Office 365 commonly return when sending emails and how the Nylas Outbox endpoint abstracts this complexity away. 

HTTP 429: Too Many Requests

Most Email providers have some form of built-in user rate limiting designed to reduce server load, and HTTP 429 errors are among the most commonly-encountered errors you’ll need to handle when sending emails. Each provider has its own rules for rate limiting and recommendations for how developers should handle them. For example, the Gmail API has three situations that can trigger an HTTP 429 error:

  • User-rate limit exceeded – The user has exceeded their hourly or daily upload or download limits.
  • User-rate limit exceeded (Mail sending) – The user has exceeded their daily mail sending limitations.
  • Too many concurrent requests for user – There are too many requests being made on behalf of the user at once. This includes requests from all apps and services, not just your own. 

For the first two scenarios, the general recommendation is to use an exponential backoff process to retry the requests. Alternatively, sometimes the API will return a time to retry value that indicates a specific time in the future when you can retry the request.  

The third scenario might not be something that’s under your control. You could see better results by limiting the number of API requests your app makes at once. Still, if the user has many apps and services that integrate with their email account, you’ll need to initiate a retry process to find times that traffic for the user account is low. 

These scenarios can sometimes be resolved via request batching: grouping multiple requests together into a single request to reduce the total number of API interactions. However, batching isn’t always an option for every use case, so it’s something that developers need to take a closer look at to understand if it fits their needs.

One crucial thing to keep in mind is that the Gmail API doesn’t immediately start reporting 429 errors when a user hits their bandwidth or email sending limits; API requests to send an email that return a successful 200 status code during this time might not actually get sent. This delay can take several minutes, so you will need custom logic to ensure that the emails you intended to send got sent.

Microsoft has similar rate limits for their email APIs for Exchange, Outlook, and Office 365; their general advice matches Gmail’s. With that said, self-hosted versions of Exchange have several configuration possibilities for rate limiting, meaning that rate limiting for Microsoft email accounts can vary at the individual level. You’re likely to encounter this problem if you need to support Microsoft email accounts.

HTTP 5XX Server Errors

Email APIs can return a handful of HTTP 5XX errors to indicate when their API service has encountered an internal issue; this group of errors includes 502 Bad Gateway, 503 Service Unavailable, and 504 Gateway Timeout. In general, most APIs consider it acceptable to retry requests that result in one of these errors. The recommendation is to make any subsequent retries in an exponential backoff pattern. 

HTTP 403: Rate Limit Exceeded (Gmail Only)

The Gmail API uses HTTP 403 errors to indicate when a user or app has exceeded API rate-limits across all of Google’s services. The Gmail API will return HTTP 403 errors in two scenarios:

  • User Rate Limit Exceeded – The user has exceeded their individual API rate limit. You can often resolve this via retries with an exponential backoff pattern.
  • Daily Limit Exceeded – Your app has exceeded the number of API requests allowed in a single day. You can only resolve this by requesting a larger API quota from Google, which may result in additional cost.

How the Nylas Outbox Endpoint Abstracts Email Error Handling

The Nylas Outbox endpoint abstracts away these difficulties by auto-detecting when a user reaches their bandwidth or concurrent request limits. We also implement an automatic retry policy for HTTP 5XX errors on your behalf too. When any of these errors occur, the Nylas Sync Engine stores the email and sends it as soon as the third-party API lifts the restrictions; we handle the entire task of managing the retry process. At any time, you can check on the status of an email sent via the Outbox endpoint by making a GET request. 

curl -X GET 'https://api.nylas.com/outbox' \
-H 'Authorization: Bearer ACCESS_TOKEN'

If the email is unsent, it will have a status of pending, and will include a send_at attribute that indicates the next retry time:

[
  {
    "send_at": 1008720000,
    "status": "pending",
    "subject": "One Email API to rule them all",
    "body": "Keep it secret, keep it safe... or share it with your friends.",
    "id": "l0trru13z"
    "to": [{
        "email": "[email protected]",
        "name": "Frodo Baggins"
  }
]

Outbox is only one component of the lean-code solutions Nylas provides for communications integrations, and it pairs well with other features we offer like Email Categorization, Clean Conversations, and Signature Extraction. If you’re ready to build your email integration today, sign up for a free account.

Related resources

How to Send Emails Using an API

Key Takeaways This post will provide a complete walkthrough for integrating an email API focused…

How to build a CRM in 3 sprints with Nylas

What is a CRM? CRM stands for Customer Relationship Management, and it’s basically a way…

How to create an appointment scheduler in your React app

Learn how to create an appointment scheduler in your React app using Nylas Scheduler. Streamline bookings and UX with step-by-step guidance.