twilio-reliability-patterns

Handle Twilio 429 errors with exponential backoff: start at 100ms, double per attempt, add ±10% random jitter, and cap delays at 30 seconds. Retry up to 5 times, and never retry non-429 errors since those indicate real failures.

Send bulk SMS with a rate-limited dispatch loop sized to your number pool, not your desired speed. A pool of 10 long codes supports roughly 10 SMS per second; use Messaging Services to pool numbers and multiply throughput.

Twilio throughput varies by number type: long codes send about 1 SMS per second, toll-free about 3 per second, and short codes 10-100 per second. Messaging Services sum the throughput of all numbers in the pool.

StatusCallbacks fail under load because 50 concurrent calls generate about 300 webhook invocations per second, exceeding limits like Twilio Functions' 30 concurrent executions. Use a thin-receiver pattern: queue the event, respond 200 immediately, and process asynchronously.

Prevent duplicate webhook processing by using the composite key {CallSid}-{CallStatus} as an idempotency key. Twilio retries callbacks on timeout, so deduplicate events before updating your database.

You cannot increase per-number throughput or configure StatusCallback retry behavior; Twilio retries on timeout automatically. To scale, add numbers via Messaging Services and request CPS increases through support before launching campaigns.