Rate Limits
Most partner APIs limit how many requests an account may make per second. That limit belongs to your account at the partner. Your own systems and every other integration draw on it too. A destination’s request rate limit keeps Zeotap inside a share of it that you choose.
One limit for every sender
A destination can be written to by many things at once:
- several syncs (one per model, plus audience syncs), each running separately;
- journey send steps;
- event forwarding rules;
- realtime syncs;
- child workspaces the destination is shared with.
The rate limit is enforced across all of them together. Every sender draws from one shared budget for the destination. For example, five syncs that start at the same moment against a destination limited to 10 requests per second send 10 requests per second between them, not 50.
When the partner answers 429 Too Many Requests, or says its rate-limit window is spent (X-RateLimit-Remaining: 0), every sender to that destination pauses until the partner’s reset time, capped at one minute. Senders don’t keep discovering the same limit one request at a time.
Setting a limit
Open the destination and find Request rate limit:
| Field | Meaning |
|---|---|
| Requests per second | The sustained rate across every sender. Leave empty for no limit. Accepts fractions (0.5 is one request every two seconds). |
| Burst (optional) | How many requests may go at once after a quiet spell. Leave empty for the automatic value, a tenth of a second’s worth (at least 1). |
The limit can also be set with the destinations API, as rate_limit on create or update:
{ "rate_limit": { "requests_per_second": 10, "burst": 5 } }On update, leaving rate_limit out keeps the current limit, and "rate_limit": null removes it.
A changed limit applies from the next run of each sync or journey. Event forwarding and realtime syncs pick it up within a minute or two.
Events forwarded to a rate-limited destination are delivered in small batches (every few seconds, or sooner once 50 events are waiting) rather than one request per event, so they can be paced alongside everything else sent to it.
What counts as a request
- API destinations: one request is one HTTP call to the partner, retries included.
- Database, warehouse and file destinations (PostgreSQL, MySQL, Snowflake, S3 and similar): one request is one batch written.
Things to know
- Choose a share, not the whole limit. If a partner allows 1,000 requests per second and your own backend also uses the account, set the destination below 1,000 so your backend keeps room.
- The limit is per destination, not per partner account. Two destinations holding keys to the same partner account each get their own budget. Set their limits so they add up to what you want.
- Syncs slow down rather than fail. A limited sync waits for its turn instead of sending and being refused, so large syncs to a tightly limited destination take longer.
- Destinations without a limit are sent to as fast as each sync allows, as before.