Rate Limiting

Rate Limiting restricts the number of API requests a client can make within a given time window. It protects the API infrastructure from overload, ensures fair usage across all customers, and prevents abuse or accidental runaway loops.

What is Rate Limiting?

Rate Limiting is a traffic control mechanism that caps how many API requests a single client (identified by API Key or IP address) can make within a defined time window. For example, a limit of 100 requests per minute means that the 101st request within that minute is rejected with HTTP status 429 (Too Many Requests). The client must wait until the window resets before sending new requests.

Rate Limiting operates at multiple levels: per-endpoint (e.g., sending messages may have tighter limits than reading contacts), per-account (total requests across all keys), and sometimes per-channel (WhatsApp imposes its own limits separate from the API layer). Understanding these layers helps you design applications that work within the boundaries reliably.

Why is Rate Limiting Important?

Without Rate Limiting, a single malfunctioning script could flood the API with millions of requests, degrading performance for everyone. Rate limits serve three purposes: Infrastructure protection -- they prevent server overload and maintain consistent response times for all users. Fair usage -- they ensure no single customer monopolizes shared resources. Abuse prevention -- they stop spam bots and compromised API Keys from causing large-scale damage.

For developers, Rate Limiting also acts as a safety net. A bug in a retry loop could send thousands of duplicate messages -- rate limits catch that before it becomes an expensive problem. They force you to write robust code with proper error handling, backoff strategies, and queue management.

Practical Example

Imagine you are building a campaign feature that sends WhatsApp messages to 10,000 contacts. Without rate awareness, your code might try to fire all 10,000 requests simultaneously. The API would reject most of them with 429 errors, your campaign would partially fail, and you would waste credits on retries.

The right approach: Check the response headers for rate limit information. SendSeven returns headers like X-RateLimit-Limit (max requests), X-RateLimit-Remaining (requests left), and X-RateLimit-Reset (when the window resets). Use these to pace your requests. Implement exponential backoff: if you get a 429, wait 1 second, then 2, then 4 -- do not hammer the API immediately.

Queue-based architecture: For high-volume sending, use a message queue (Redis, RabbitMQ, or a simple in-memory queue). Push all 10,000 recipients into the queue, then consume at a rate that stays below the limit. This approach is resilient, measurable, and prevents wasted API calls. SendSeven's campaign feature (Reach) handles this automatically.

Rate Limiting with SendSeven

SendSeven applies rate limits at the API Key level. Current limits depend on your plan tier -- higher plans get higher throughput. All responses include rate limit headers so your application always knows its current status. When you hit a limit, the API returns a clear 429 response with a Retry-After header indicating how many seconds to wait.

For bulk messaging, we recommend using SendSeven's built-in Reach (Campaigns) feature rather than individual API calls. Campaigns are processed server-side with optimized throughput, automatic pacing per channel (respecting WhatsApp's own rate limits), and delivery reporting -- no rate limit management needed on your end.

Full rate limit documentation, including per-endpoint limits and code examples for implementing backoff strategies, is available at docs.sendseven.com.