Author picture Eric Tran

How to Solve Iterable: Exceeded Rate Limit for Webhooks

Published · Updated


When an upstream provider sends a bulk update or increases webhook delivery throughput, it may trigger Iterable’s API rate limit. For example, imagine triggering a SendGrid campaign that overwhelms Iterable with webhooks.

In this article, I’ll explain how to solve Iterable’s rate-limiting issues by using Hookdeck as a queue to throttle the request rates.

Iterable errors caused by rate limiting

Once the rate limit is triggered, Iterable will respond with the 429 Too Many Requests error to the new and incoming webhooks. This means you are dropping those webhooks until Iterable starts accepting them again.

The rate limit differs per endpoint. For example, the bulk track event has a rate limit of 10 requests/second, per project while export Data CSV has a rate limit of 4 requests/minute, per project.

How can you reduce your risk of losing webhooks by complying with Iterable’s rate limit?

Introducing a message queue to solve the request rates limit

The answer: by introducing a message queue! By decoupling the ingestion and processing of events, you can throttle the delivery of the webhooks to your server. This allows you to manage the throughput and comply with Iterable’s rate limit.

Rate limit webhooks with Hookdeck

With Hookdeck you can manage your throughput. Controlling the speed at which your services receive webhooks will solve the rate limitation.

How to set up Hookdeck’s rate limit

  1. Create a Connection.

Sendgrid to iterable screenshot

  1. Select your Destination and click the three dots to edit.
  2. Check the Enable delivery rate limiting box.
  3. Enter 8 requests per second as your rate limit.
    • Iterable’s rate limit for bulk track events is 10 requests per second, but best practice recommends leaving a safety margin to avoid triggering the rate limit.

Iterable analytics screenshot

  1. Replace your webhook endpoint with Hookdeck’s URL.

That’s it! You are all set up.

Conclusion

In 4 short steps, we successfully managed to introduce a message queue to control your request rates. Now you’ll be receiving webhooks at a pace of 8 requests per second, and in turn will avoid triggering Iterable’s rate limit.