SafeWebhook/ Error HTTP 429
Launch Workbench
HTTP Status Code 429

Fix HTTP 429 Rate Limit Errors and Webhook Throttling

Learn how to handle and resolve HTTP 429 Too Many Requests errors in high-volume webhook systems. Configure Retry-After headers and smooth traffic spikes.

Direct Answer / Root Cause Diagnosis

An HTTP 429 Too Many Requests error occurs when your webhook receiver or API gateway rate limiter throttles incoming events due to sudden traffic bursts. To prevent dropped events, configure Retry-After headers and buffer events with an edge queue.

Key Diagnostic Takeaways

  • Cause: Burst of webhook events exceeded your API gateway rate limit threshold.
  • Risk: If retries are exhausted, critical financial or user sync events may be dropped.
  • Fix: Add webhook endpoint to rate limiter whitelist or use an edge buffer.
  • Simulate: Test Retry-After header handling in SafeWebhook.

Common Root Causes for HTTP 429

Global API Rate Limiter Applied to Webhook Endpoints

Applying the same IP-based rate limiter (e.g. 60 req/min) to webhook routes throttles legitimate batch dispatches from providers like Stripe or Shopify.

Batch Sync Events or Mass Updates

Creating 10,000 subscriptions or bulk editing products causes providers to dispatch thousands of concurrent webhooks within seconds.

Provider Retry Schedules for HTTP 429

How major webhook senders retry when receiving status 429:

Webhook ProviderRetry Schedule & BackoffMax Window
StripeHonors Retry-After headers with exponential backoff72 hours
ShopifyBacks off and retries over 48 hours48 hours

Step-by-Step Resolution Checklist

1
Exclude `/api/webhook/*` routes from standard user rate limiters.
2
Return a valid `Retry-After: 60` header when 429 is unavoidable.
3
Buffer high-throughput webhooks using Cloudflare Queues or AWS SQS.
4
Monitor provider webhook delivery failure metrics in your dashboard.

Production Code Fix Recipe

Node / Express / Python
// Solution: Exclude Webhooks from Rate Limiter & Return Retry-After
import rateLimit from 'express-rate-limit';

const generalLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
  skip: (req) => req.path.startsWith('/api/webhook') // Whitelist webhooks
});

app.use(generalLimiter);

// Webhook-specific backpressure handler
app.post('/api/webhook', (req, res) => {
  if (isSystemOverloaded()) {
    res.setHeader('Retry-After', '60');
    return res.status(429).json({ error: 'System overloaded, retry in 60s' });
  }
  res.status(200).json({ ok: true });
});

How to Test & Simulate HTTP 429 in SafeWebhook

  1. In SafeWebhook Response Config, select HTTP 429.
  2. Add custom header `Retry-After: 30`.
  3. Trigger webhooks to verify upstream backoff cadence.

Frequently Asked Questions: Webhook HTTP 429

Do webhook senders respect Retry-After headers?

Yes. Modern providers like Stripe, Resend, and Clerk read the `Retry-After` header and delay subsequent retry attempts accordingly.

Simulate HTTP 429 in 1 Click

Test your application error resilience and webhook retry mechanisms in real-time.

Launch Error Simulator →

Troubleshoot Other Webhook Errors