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 counts rate limits per workspace, not per API key; login and authentication endpoints count per IP address. Each limit applies to a rolling 60-second window, and your integration shares that budget with the dashboard. The limits are the same on every plan. Every response includes the X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers, so your application always knows where it stands. When you exceed a limit, the API returns a 429 response with a Retry-After header that tells you how many seconds to wait.

For bulk messaging, use SendSeven's built-in Reach (Campaigns) instead of individual API calls. Campaigns run on the server: you set the send speed and batch size, and on WhatsApp you can split a large send over several days to protect a new number. You don't need your own rate limit handling for that.

The current values are in the API documentation at docs.sendseven.com. Best practice: watch X-RateLimit-Remaining, slow down before it reaches zero, and queue requests on the client side so a 429 never reaches your users.