Skip to content
Oct 3, 2026NewsletterRSS

Nylas Now Returns a 429 When Mail Providers Throttle Sends

Nylas now passes provider rate limits through as a 429 with Retry-After, and no longer reports IMAP throttling as a 504 timeout.

2 min read

NylasMailbox APIs

Hand-drawn illustration of a mailbox with a stopwatch beside it on a sky blue background

Nylas now returns a 429 as soon as a mail provider throttles a send, and includes the provider’s Retry-After header when there is one, the company said in an Oct. 1 changelog entry. A client that hits a limit now gets a signal it can act on.

Throttled sends now say so

When an SMTP server answers 421 too many commands on an IMAP grant, the Nylas API now returns 429 Too Many Requests instead of 504 Gateway Timeout, according to the same entry. A 504 tells a client the request may have failed for any reason. A 429 tells it to wait and try again.

The Oct. 1 entry also says drafts on IMAP grants now match the MIME format of sent messages. Nylas said that fixes compatibility with clients such as Outlook Desktop.

Earlier fixes covered retries

Nylas said in a Sept. 28 changelog entry that an Idempotency-Key could stay stuck in the in_progress state if the client disconnected mid-request. That blocked retries. The key now clears after a disconnect.

The same entry says send requests could stall past the SDK’s timeout. The cause was a wrong port fallback during STARTTLS negotiation. The API now retries transient Microsoft Graph failures on send and draft-send paths. Sends triggered by workflows now retry on rate limits instead of failing at once.

Workflows get logs and a stricter check

Workflow runs now appear in the Dashboard under Logs > System, Nylas said. Filtering by “Workflows” shows each run’s trigger, skip reasons, send and failure attempts and final counts.

A workflow that pairs from.email with a grant-level template now gets a 400 when it is created. Before, it was created and then failed on every send. Nylas said application-level templates are required.

Key takeaways

  • Provider throttling on send now comes back as a 429, with Retry-After when the provider supplies it.
  • IMAP 421 too many commands responses are a 429, not a 504.
  • A stuck Idempotency-Key after a client disconnect is fixed.
  • Workflows that can never send now fail at creation with a 400.

The take

We think a clear error code is worth more than most new features. A 504 leaves a client guessing. The usual guess is to retry right away. Against a provider that is already throttling, that makes the problem worse.

A 429 with a wait time lets the client back off for the right amount of time. It also lets a team tell two problems apart: a provider limit and a fault inside Nylas.

Teams on Nylas should check how their retry code treats a 504. If it retries at once, it should now read Retry-After and wait that long. They should also confirm that every retried send carries an Idempotency-Key. Without one, a retry can send the same message twice.