WhatsApp error 80007 (rate limit issues): too many calls for one WhatsApp Business account

WhatsApp error 80007 means your app has made too many API requests for one WhatsApp Business account in the current hour. Meta's error reference titles it "WhatsApp Business Account Rate Limit" (HTTP 429 Too Many Requests): "The WhatsApp Business Account has reached its rate limit." Its advice is to see the account rate limits, "try again later or reduce the frequency or amount of API queries the app is making." The limit is scoped to one account, which makes it easier to trace than the app-wide error 4.

The numbers

Meta's WhatsApp rate-limits documentation sets request limits per app and per account (Meta now calls the account a Messaging account):

Two consequences follow. A brand-new account, before its number is registered, has only 200 requests an hour, so an onboarding script that retries in a loop can use it up quickly. And because the limit is per app, a second app working on the same account (for example your own script beside a platform's app) has its own allowance, but each one can still hit its own ceiling.

Message sending speed is governed separately by throughput, 80 messages per second per number by default, and exceeding it gives 130429. If your campaign gets 80007, look at the other calls running for the same account.

What the error looks like

Illustrative response:

{
  "error": {
    "message": "(#80007) There have been too many calls to this WhatsApp Business account.",
    "type": "OAuthException",
    "is_transient": true,
    "code": 80007,
    "fbtrace_id": "AzR4mW9qPn2TkV6sLx1bCeJ"
  }
}

The usage header on earlier responses, keyed by the account ID (illustrative values):

X-Business-Use-Case-Usage: {"104857362291847":[{"type":"whatsapp_business_management","call_count":97,"total_cputime":12,"total_time":15,"estimated_time_to_regain_access":0}]}

call_count, total_cputime and total_time are percentages of the allowance. When a limit is hit, estimated_time_to_regain_access tells you, in minutes, how long to wait.

Common causes

• Template polling. Fetching each template's status one by one every minute instead of listing them in one call and listening to message_template_status_update webhooks.
• Onboarding loops. A script that keeps calling registration, phone number or subscription endpoints while waiting for something to finish, on an account that still has the 200-request allowance.
• Health checks per screen. A dashboard that fetches phone number quality and messaging limit each time it loads.
• Analytics pulls over long date ranges split into many small requests.
• Two systems on one account, each unaware of the other's jobs.

Step-by-step fix

1. Note the account ID in the failing call and pause non-urgent jobs for that account.
2. Read estimated_time_to_regain_access from the header and wait at least that long before retrying.
3. List calls for that account over the last hour by endpoint. Polling jobs usually stand out.
4. Batch reads. One GET /<WABA_ID>/message_templates?fields=name,status,language,category&limit=100 replaces dozens of single-template calls.
5. Move to webhooks for template status, account updates and message statuses.
6. Cache phone number details and business profile; refresh on a webhook or every few hours.
7. Retry with back-off after the wait. A request rejected for a rate limit was not processed, so retrying a send is safe.

A worked example

Priya, a developer at a Jaipur travel agency, writes a setup script for the agency's new WhatsApp Business account. It creates 30 itinerary and payment-reminder templates, then checks each template's status every two minutes until all are approved, and also polls the phone number while the team finishes registration. The number is not registered yet, so the account has the 200-requests-an-hour allowance. Within the first hour the script hits 80007 and the template creation calls start failing too.

She changes the script to list all templates in one call every 15 minutes and subscribes to template status webhooks. After the number is registered, the account moves to the 5,000-requests-an-hour allowance and the remaining work fits comfortably. Template creation has its own separate limit of 100 new templates an hour per account, so she also spreads creation over two runs for future batches.

Preventing 80007

• Budget calls per account, especially during onboarding.
• One list call, not many item calls, wherever an endpoint supports listing.
• Webhooks for anything that changes state.
• Read the usage header and slow background work when it climbs.

How Broadchat handles account rate limits

Broadchat's Meta client reads X-Business-Use-Case-Usage for each account, postpones background refreshes such as template sync and channel health when usage is high, and honours estimated_time_to_regain_access when Meta asks it to wait. It treats 80007 as a rate-limit rejection, so the call is retried with exponential back-off and jitter instead of being reported as a failure straight away. Template status changes reach Broadchat through Meta's webhook, and Sync Templates in CRM → WhatsApp Templates fetches the list in one pass. If you also run your own scripts against the same account, they use your app's separate allowance.

Related: error 4, the app-wide limit, the WhatsApp API error codes cheat-sheet and messaging limit tiers, which are a different kind of limit.