Build with Engage

Rate limits

Honest version: authentication is throttled, and the endpoints your integration uses are not. Here is what that means for you.

What is limited today

The unauthenticated endpoints, because they are the ones worth attacking — sign-in, sign-up, token refresh and invitation acceptance. Limits apply per account and per address separately, so one person failing a password cannot lock out everybody sharing a network, and one address cannot work through a list of accounts.

sign-in       5 failures per account    / 15 minutes
              20 failures per address  / 15 minutes
sign-up       10 attempts per address  / 1 hour
refresh       20 failures per address  / 15 minutes
invitation    10 failures per address  / 15 minutes

A correct sign-in clears the account counter, so a colleague's typos do not punish you. The address counter is deliberately not cleared — otherwise someone with one valid account of their own could refill their budget at will between guessing runs.

What is not limited

/v1/events and /v1/customers — the endpoints an API key can reach — carry no published rate limit today.

Do not read that as permission to hammer them. It means a limit has not been needed yet, not that one will never exist. Build as though there is one: handle 429, back off exponentially, and do not retry in a tight loop. Code written that way keeps working on the day a limit appears; code that assumes unlimited throughput breaks on that day, in production, at whatever moment made the limit necessary.

Meeting a limit

HTTP/1.1 429 Too Many Requests
Retry-After: 847

{
  "error": {
    "code": "rate_limited",
    "message": "Too many attempts. Try again in 15 minute(s)."
  },
  "request_id": "req_..."
}

Retry-After is in seconds and is never zero. Wait for it. Retrying sooner does not shorten the block and, on the endpoints where the block extends on repeated attempts, will lengthen it.

The WhatsApp limit you will actually meet first

Meta rate-limits sending, and applies quality-based messaging tiers to every business number. A new number starts able to message a limited number of unique customers in a rolling twenty-four hours, and the tier rises as the number builds a history of messages people do not block or report.

That ceiling is far more likely to constrain a growing integration than anything on this page, and it is not something an API can raise for you — it is earned by sending messages customers want. Which is the same reason opt-in and the suppression list are enforced on every send rather than left to each caller: a business that messages people who did not ask gets its number throttled, then blocked, and the platform cannot undo that on its behalf.