Messenger error 613: Calls to this API have exceeded the rate limit

Code 613 means you crossed a custom rate limit, one defined by the specific API you are calling rather than the platform-wide application quota. Meta's rate-limiting guide describes it as "a custom rate limit has been reached" and points you to the docs of the API in question; on the Messenger Platform that usually means one of the documented per-Page ceilings: 200 calls per 24 hours multiplied by the Page's engaged users, 300 Send API calls per second per Page for text-type messages, 10 per second for audio and video, 2 conversations API calls per second, or the tight 10-calls-per-10-minutes limit on the Messenger Profile API.

The engaged-users formula explains 613's signature behavior: it almost never fires during development, then appears on launch day. A Page with 50 people who can be messaged gets 10,000 calls a day; a test Page with 2 gets 400. Bots that poll, resend on timeout without idempotency, or set the persistent menu on every deploy burn through the smaller quotas first, the Profile API limit is by far the easiest to hit accidentally.

613 also has documented subcodes worth separating: 2534040 is the plain per-Page throttle, while 2018338 is not a volume problem at all but a policy warning about message-tag abuse toward one person. Subcode 1996 indicates Meta noticed inconsistent call-volume behavior from your app. And 613 is only one member of the throttling family: 4 is the app-level quota, 17 the user-level one, 32 the Page-token quota, and 80006 the Messenger business-use-case limit. All of them are retryable, but only after you slow down; continuing to hammer the endpoint extends the block.

{
  "error": {
    "message": "(#613) Calls to this api have exceeded the rate limit.",
    "type": "OAuthException",
    "code": 613,
    "fbtrace_id": "Fz54k3GZrio"
  }
}

Build the rate limiter into your sender, not around it: a per-Page token bucket at a safe fraction of the documented ceilings, with media on its own bucket. Watch the usage headers in every response and treat 80% as an alarm. Make sends idempotent so retries never duplicate. The documented numbers, including the engaged-users formula and the profile-API caps, are collected in the Messenger limits reference; the launch-day symptom pattern is described in the troubleshooting guide.