Messenger Platform · error code

Messenger error 80006: Messenger business use case rate limit

RetryableHTTP 400Rate limits & throttling

Last verified against Meta for Developers - Messenger Platform error codes

What error 80006 means

Code 80006 is the Business Use Case (BUC) rate-limit code assigned to Messenger. Meta's rate-limiting guide maintains a table mapping each 8000x code to a product, 80001 for Pages, 80002 for Instagram, 80008 for the WhatsApp Business Management API, and 80006 for Messenger, and states that when an app reaches its BUC limit, "subsequent requests made by your app will fail and the API will respond with an error code." The documented sample for the family reads "(#80001) There have been too many calls to this Page account. Wait a bit and try again," with 80006 following the same shape for Messenger calls.

BUC limits are metered per business object, here, per Page, on Page or system-user tokens, which makes 80006 the modern, correctly-scoped signal for "this Page is over its Messenger budget": the pool computed as 200 calls x engaged users per rolling 24 hours. The accompanying X-Business-Use-Case-Usage header itemizes usage per business object ID with call_count, total_cputime, total_time percentages and, crucially, estimated_time_to_regain_access in minutes, the only place Meta tells you how long a throttle will last.

Handle it like the rest of the family (4, 17, 32, 613): stop calling, wait out the stated interval, resume slowly. Meta's best-practices list is explicit that continuing to call while throttled increases the call count and delays recovery.

What it looks like

{
  "error": {
    "message": "(#80001) There have been too many calls to this Page account. Wait a bit and try again. For more info, please refer to https://developers.facebook.com/docs/graph-api/overview/rate-limiting.",
    "type": "OAuthException",
    "code": 80001,
    "fbtrace_id": "AmFGcW_3hwDB7qFbl_QdebZ"
  }
}

Why it happens

  • The Page's Messenger call pool (200 x engaged users / 24h) exhausted on a Page or system-user token.
  • Broadcasts or migrations replaying large message volumes through one Page.
  • Uncached profile lookups and conversation reads scaling with traffic.
  • Retry loops during an incident consuming the remaining budget.
  • Low-engagement Pages (few engaged users) with automation sized for bigger pools.

How to fix Messenger error 80006

  1. 1Stop all Messenger calls for the affected Page immediately.
  2. 2Parse X-Business-Use-Case-Usage for the Page's ID and wait at least estimated_time_to_regain_access minutes.
  3. 3Resume with a fraction of normal throughput and ramp up while watching call_count.
  4. 4Cut discretionary calls first (profile enrichment, read syncs) to preserve budget for customer-facing sends.
  5. 5Re-architect chronic offenders: webhooks over polling, caching over refetching, batching where supported.

How to stop it recurring

Make X-Business-Use-Case-Usage a first-class metric: export the percentages per Page to your monitoring and alert at 80%. Size automation to each Page's actual engaged-user pool rather than a global assumption. Keep an emergency kill switch that halts non-essential Graph traffic per Page, the difference between a blip and an outage is how fast you stop calling. The BUC mechanics and every documented Messenger ceiling are tabulated in the limits reference.

Official reference: Meta for Developers - Messenger Platform error codes. See all Messenger error codes or the Messenger limits and quotas.

Related codes

Error 80006 - quick answers

What does Messenger error 80006 mean?

Code 80006 is the Business Use Case (BUC) rate-limit code assigned to Messenger. Meta's rate-limiting guide maintains a table mapping each 8000x code to a product, 80001 for Pages, 80002 for Instagram, 80008 for the WhatsApp Business Management API, and 80006 for Messenger, and states that when an app reaches its BUC limit, "subsequent requests made by your app will fail and the API will respond with an error code."

How do I fix Messenger error 80006?

1. Stop all Messenger calls for the affected Page immediately. 2. Parse X-Business-Use-Case-Usage for the Page's ID and wait at least estimated_time_to_regain_access minutes. 3. Resume with a fraction of normal throughput and ramp up while watching call_count. 4. Cut discretionary calls first (profile enrichment, read syncs) to preserve budget for customer-facing sends. 5. Re-architect chronic offenders: webhooks over polling, caching over refetching, batching where…

Can I retry after error 80006?

Yes - this is a retryable condition. Back off (start around one second and double on each attempt, with jitter) and watch for a retry-after hint from the platform before resending.

Stop debugging Messenger by hand

Connect the channel through Conferbot: tokens, webhooks and retries are handled, failures show as readable status.