rate_limited — Too many requests
What the API returns
{
"error": {
"code": "rate_limited",
"message": "Too many requests.",
"request_id": "req_01JRQ8F4X9N2K7YB3C5V6W8H0T"
}
}Every Wapito error is this one envelope. Branch on code, which is stable; message is written for people and can be reworded; details appears only when there is something specific to say; request_id is what to quote to support.
What it means
rate_limited is an HTTP 429 error from the Wapito WhatsApp API: too many requests. The response message reads “Too many requests.” It is retryable: the same request can succeed later without changes. 4 endpoints can raise it, GET /groups among them.
Why it happens
You exceeded the request rate the API accepts for this channel. This is an API-level limit that protects the platform from a runaway loop, and it counts every call including reads, not just sends. Concurrency is the usual cause: a worker pool that fans out over a contact list will produce a burst that no single-threaded script ever would, and the limiter sees the burst rather than your intent.
How to fix rate_limited
Back off exponentially with jitter rather than retrying immediately, and cap the number of attempts.
Reduce worker concurrency for this channel to one and let the send queue do the pacing for you.
Cache read-only data such as the group list instead of fetching it before every single send.
The same failure in other stacks
If you are moving from a library or a self-hosted gateway, this is the same failure under the name that stack gives it:
rate-overlimit
Endpoints that raise it
Where you will meet it
- Send Group Message
Feature guide
Retry guidance
Safe to retry
The condition is transient, so the same request can succeed later without any change on your side. Retry with exponential backoff and jitter — start at one second, double each attempt, cap at a minute — and stop after a handful of tries so a stuck condition surfaces as an alert rather than a hot loop.
On a 429, read the Retry-After header first when the response carries one — rate_limited always sends it, in seconds — and when the details object names a window or a reset time, wait for exactly that. Both beat a guessed backoff.
Frequently asked questions
How is this different from send_rate_limited?
rate_limited counts API calls of every kind against a request budget. send_rate_limited is specifically about the per-channel send queue being saturated, which is an anti-ban control rather than a capacity one. Fixing the first means fewer calls; fixing the second means sending more slowly.
Does a 429 consume my monthly request allowance?
A refused request is rejected before any work happens, so it does not consume send quota. It is still a request that hit the edge, so the safest assumption is that hammering a limiter is never free. Back off properly and the question stops mattering.
Related
Try it on your own number
Create a channel, link a WhatsApp number by QR or pairing code, and call the API in a couple of minutes. The Sandbox plan is free and needs no card.