Rate Limiting

Outcome: Understand RATE_LIMITED on webhook calls, read retryAfterSeconds, and know what to do about it. Audience: Everyone / Developers · Tags: troubleshooting, rate_limit, webhook

This page is about inbound rate limiting: how many requests SnapLink's webhook ingress will accept. (For an outbound connector being throttled by the destination app — e.g. Slack rate-limiting SnapLink — see the rate_limit row in Connector failed; that's a different limit, applied by the destination, not by SnapLink.)

Symptom: a webhook call returns 429 / RATE_LIMITED

Webhook requests are checked against three fixed-window limits, in this order — per source IP, per flow endpoint, and per workspace. Whichever one you exceed first is the one that trips:

Limit	Default	Meaning
Window size	60 seconds	The rolling window each count resets on.
Per endpoint	120 requests / window	Requests to one specific flow's webhook.
Per IP	240 requests / window	Requests from one source IP, across all flows.
Per workspace	600 requests / window	Requests across every flow in one workspace.

Exceeding any of these returns:

{ "ok": false, "error": { "code": "RATE_LIMITED", "message": "Too many requests.", "details": { "retryAfterSeconds": 37 } } }

details.retryAfterSeconds tells you exactly how long to wait before the window resets and requests will be accepted again — don't guess, read it.

What to do

1. Read retryAfterSeconds from the error response and wait at least that long before retrying.
2. Add backoff on the sending side — if the system calling your webhook retries automatically, make sure it backs off rather than immediately hammering the same URL again (a retry storm just re-triggers the limit).
3. Spread load out. If you're sending a burst (e.g. a bulk import firing one webhook call per record), batch multiple events into fewer calls where possible, or throttle the sender to stay under the per-endpoint limit.
4. Ask your operator to raise the limits if your legitimate traffic regularly needs more headroom than the defaults allow — the thresholds are environment variables (RATE_LIMIT_WINDOW_SECONDS, RATE_LIMIT_PER_ENDPOINT, RATE_LIMIT_PER_IP, RATE_LIMIT_PER_WORKSPACE) and can be raised per instance. See Administration.

Advanced diagnostics

• A rate-limited request is rejected before it's checked for a valid secret or flow status in the per-IP case, so a flood of bad requests can't be used to brute-force a webhook secret at high speed.
• Rejected (rate-limited) requests are still recorded as metadata, so you can confirm after the fact that a burst was throttled rather than lost silently — see Webhook issues for how to check.

When to contact support

You're seeing 429 at what you believe is low, normal traffic volume (well under the defaults above), or the limits seem misconfigured for your instance. Include the flow name, roughly how many requests/second you're sending, and the retryAfterSeconds value you saw.

---

Related: Webhook issues · Flow not running · Connector failed

Was this helpful? 👍 👎