Rate limits

Limits are per-endpoint token buckets scoped to your workspace — not to your plan. Burst is how many requests you can fire back-to-back from a full bucket; sustained is how fast it refills. Separately, how fast WhatsApp actually delivers is governed by the messaging tier Meta assigns your phone number. When a workspace has more than one key, each key may use at most half of any bucket.

Every answer says what is left. Each response, a success or an error, carries three headers for the bucket the request used: RateLimit-Limit (the bucket’s burst size), RateLimit-Remaining (requests left) and RateLimit-Reset (seconds until the bucket is full again). When a request uses more than one bucket (your key’s half and the workspace’s), they describe the one closer to running out. A 401 has none (no bucket was used), and neither has an answer given while the limiter cannot be reached.

# A success from POST /send (bucket: 200, refilling 50 a second)
HTTP/1.1 200 OK
RateLimit-Limit: 200
RateLimit-Remaining: 187
RateLimit-Reset: 1

# The bucket is empty
HTTP/1.1 429 Too Many Requests
Retry-After: 1
RateLimit-Limit: 200
RateLimit-Remaining: 0
RateLimit-Reset: 4

A retry after a 429 or a dropped connection is safe with an Idempotency-Key: see Idempotency.

Each resource page lists the rows for its own endpoints.