Messenger error 613: API calls exceeded the rate limit
Last verified against Meta for Developers - Messenger Platform error codes
Calls to this api have exceeded the rate limit.What error 613 means
Code 613 with subcode 2534040 is the Messenger Platform's explicit per-API throttle: "Calls to this api have exceeded the rate limit," with Meta's remedy stated just as plainly, "your app has reached the rate limit. Pause API calls and try again later." It is the subcoded, Messenger-specific sibling of the bare 613, and in the current error-codes table it is listed in the context of the Instagram and Messenger messaging APIs, where per-second and per-Page ceilings are documented individually.
The ceilings that matter: the Send API accepts 300 calls per second per Page for messages containing text, links, reactions and stickers, but only 10 per second for audio or video content; the conversations API allows 2 calls per second per Page; private replies to post comments are capped at 750 calls per hour. Meta also documents that an app "may be rate limited if too many messages are being sent to a single thread," a per-conversation throttle with no published number, which is the one that catches bots streaming long answers as many rapid messages to one person.
Handling is the standard discipline: pause, back off with jitter, resume slowly. What distinguishes 2534040 from the app-wide code 4 is scope, other Pages and other endpoints keep working, so your limiter should isolate the affected Page or endpoint rather than halting globally.
What it looks like
{
"error": {
"message": "(#613) Calls to this api have exceeded the rate limit.",
"type": "OAuthException",
"code": 613,
"error_subcode": 2534040,
"fbtrace_id": "BLBz/WZt8dN"
}
}Why it happens
- Send bursts above 300/second per Page, typical at broadcast fan-out time.
- Audio or video sends treated like text sends; their ceiling is 30x lower at 10/second.
- Many rapid messages into a single thread (chunked bot responses, typing simulations).
- Conversations API polling beyond 2 calls per second per Page.
- Private-reply automation on viral posts exceeding 750 replies per hour.
How to fix Messenger error 613
- 1Pause calls to the affected endpoint and resume at reduced rate after a backoff interval.
- 2Shape traffic per endpoint class: separate queues for text sends, media sends, conversations reads and private replies, each with its documented ceiling.
- 3Coalesce chunked bot output into fewer messages per thread; prefer one structured message over five fragments.
- 4For broadcast spikes, pre-shard the audience over time windows instead of firing at once.
- 5Log the subcode with every 613 so volume throttles (2534040) never get conflated with the policy warning on 2018338.
How to stop it recurring
Encode the documented ceilings as constants in one shared limiter and keep a comfortable margin, 80% is a good line, since your clock and Meta's never quite agree. Give media its own budget. Treat the single-thread throttle as a UX hint: users prefer one coherent message to a burst anyway. All numbers are tabulated with sources in the Messenger limits reference; symptom-first debugging is in the troubleshooting guide.
Official reference: Meta for Developers - Messenger Platform error codes. See all Messenger error codes or the Messenger limits and quotas.
Related codes
- 613: Calls to this API have exceeded the rate limitCalls to this API have exceeded the rate limit
- 613: Message tag abuse warningWarning! You are engaging in behavior that may be considered bothersome or…
- 4: Application request limit reachedRate Limit error: Application request limit reached.
- 32: Page request limit reached(#32) Page request limit reached
- 80006: Messenger business use case rate limit
Error 613 - quick answers
What does Messenger error 613 mean?
Code 613 with subcode 2534040 is the Messenger Platform's explicit per-API throttle: "Calls to this api have exceeded the rate limit," with Meta's remedy stated just as plainly, "your app has reached the rate limit.
How do I fix Messenger error 613?
1. Pause calls to the affected endpoint and resume at reduced rate after a backoff interval. 2. Shape traffic per endpoint class: separate queues for text sends, media sends, conversations reads and private replies, each with its documented ceiling. 3. Coalesce chunked bot output into fewer messages per thread; prefer one structured message over five fragments. 4. For broadcast spikes, pre-shard the audience over time windows instead of firing at once. 5. Log the subcode…
Can I retry after error 613?
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.