Webhooks can fail under heavy API traffic for two separate reasons: your receiver may take too long to acknowledge an incoming delivery, or the API calls your handler makes may exceed a provider’s rate limit. When both happen during a burst, retries can multiply the workload. Keep the delivery handler fast, queue downstream work, and pace API requests according to the specific provider’s limits.
Two limits can be involved—and they are not the same
A webhook is an HTTP request sent to your application when an event occurs. The sender expects your endpoint to respond within its delivery rules. Separately, your application may call an API while processing that event, and that API may impose a request limit. A slow webhook response is a delivery problem; an HTTP 429 from a downstream API is a rate-limit problem. One can trigger or aggravate the other, but they do not necessarily share a timeout or retry policy.
As an Amazon Associate I earn from qualifying purchases.
“RPM” alone does not tell you how an API limit works. Limits may be measured per second or minute, apply to different scopes, allow bursts through a bucket, or include concurrency and compute-use restrictions. Read the documentation for the exact API and plan rather than treating a single requests-per-minute number as universal.
How a burst turns into repeated failures
- Events arrive close together. A burst can make many handlers compete for the same database, worker capacity, or downstream API allowance.
- Handlers do too much before responding. If a handler waits for database work or synchronous API calls, its acknowledgment can miss the sender’s deadline. Shopify says a webhook delivery fails if the app does not respond within five seconds; Shopify retries failed deliveries up to eight times at increasing intervals, then stops. The troubleshooting documentation does not specify the complete interval schedule. Shopify’s webhook troubleshooting guidance
- Retries add more work. A failed delivery may be sent again while the original work is still running. If your application also retries a throttled API call too soon, the additional calls can worsen the congestion. Shopify warns that requests made before the `Retry-After` period elapses will be throttled. Shopify REST Admin API rate limits
This can form a feedback loop: event burst, slow processing, failed delivery, redelivery, and still more concurrent work. That sequence is an operational inference from the documented timeout, retry, and throttling behavior—not a universal measured rate of failure.
What provider limits look like in practice
Shopify REST Admin API
Shopify documents a leaky-bucket model for its REST Admin API, with standard limits of 2 requests per second, 4 for Advanced Shopify, 20 for Shopify Plus, and 40 for Commerce Components. The documentation also describes a default bucket capacity of 40 requests per app and store, with larger capacity for Plus, and notes that limits may be temporarily reduced. These figures are specifically for the REST Admin API, which Shopify marks as legacy as of October 1, 2024; they are not limits for Shopify’s GraphQL Admin API or a general rule for other providers. Shopify REST Admin API rate limits
When REST requests exceed the limit, Shopify returns `429 Too Many Requests`. The `Retry-After` response header states how many seconds to wait. Sending requests before that interval expires results in further throttling.
Rank #2
GitHub API
GitHub documents both primary rate limits and secondary limits. Secondary limits may be triggered by factors including too many concurrent requests, too many requests to one endpoint, or excessive compute use. GitHub advises waiting for `Retry-After` when it is present; otherwise, follow reset metadata or, in the relevant circumstances, wait at least a minute. If secondary-limit failures continue, use exponentially increasing waits. Its guidance also recommends serial requests to avoid exceeding secondary limits. GitHub REST API rate limits GitHub REST API best practices
Recommended Free Tools
The practical lesson is to handle the response metadata and rules for the API that returned the error. Do not assume that one provider’s request rate, bucket, reset, or retry schedule applies to another.
Design the receiver to acknowledge quickly
Keep the HTTP request path short. Verify the request, durably record the event or enqueue it, then return the acknowledgment instead of waiting for all business logic and downstream calls to finish. This is an implementation pattern motivated by Shopify’s five-second failure threshold, not a guarantee that every webhook sender uses the same deadline.
A queue helps separate incoming delivery from work that can take longer. It can also smooth bursts: workers can process queued events at a controlled pace rather than launching every downstream API call at once. Shopify recommends queueing or staggering requests in its API guidance and recommends sequential sending for its App Events API. GitHub likewise recommends serial requests to avoid secondary rate limits. Shopify API limits and request pacing guidance Shopify App Events API GitHub REST API best practices
Retry without amplifying the problem
- Honor provider metadata. For Shopify REST, wait the number of seconds in `Retry-After`. For GitHub, use `Retry-After` or the documented reset guidance.
- Control concurrency. Limit how many workers can call the same downstream API at once; a queue does not help if it releases the entire backlog as a simultaneous burst.
- Use bounded, increasing delays where documented. Do not loop rapidly on 429 responses. GitHub explicitly recommends exponentially increasing waits for continuing secondary-limit failures.
- Keep webhook-delivery retries separate from API-call retries. The webhook sender controls its delivery policy; your application controls retries for its own outbound calls. Track each independently so one retry mechanism does not conceal or multiply the other.
There is no universal webhook retry schedule. Shopify documents up to eight failed-delivery retries with increasing intervals, but the cited troubleshooting page does not give the exact schedule. A 2023 Svix survey found that 25 of 83 providers specified exponential-backoff schedules; that is a survey-specific result, not a rule for all providers. Svix’s 2023 survey of webhook retry policies
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsMake repeated deliveries safe
Retries mean a receiver should not assume that every delivery represents a new event. Deduplicate before applying side effects. Shopify provides `X-Shopify-Webhook-Id` as a unique delivery identifier and `X-Shopify-Event-Id` as an identifier shared across deliveries arising from the same merchant action. Store and use the appropriate identifier for the deduplication behavior you need. Shopify HTTPS webhook delivery
Deduplication does not replace durable event handling: record enough state to know whether work was accepted and whether its side effects completed. Otherwise, a retry can be acknowledged while its work is lost, or a repeated event can apply the same change twice.
Monitor the points where the cascade starts
Track webhook acknowledgment latency and outcomes separately from downstream API status codes, rate-limit headers, and retry counts. Shopify’s delivery troubleshooting information includes response code, attempt number, payload size, and response time, and advises fixing repeated failures before subscriptions are removed. Shopify’s webhook troubleshooting guidance
Quick Recap
- Rising acknowledgment times point to work happening too early in the handler or insufficient receiving capacity.
- 429 responses point to outbound API calls that need better pacing, concurrency limits, or retry handling.
- Repeated delivery attempts alongside 429s can indicate that both problems are interacting; inspect their timelines rather than treating them as one generic “RPM” failure.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
