Search ‘Instagram API DM limit per hour’ and you will find three different numbers — 200, 2,000, 5,000 — each stated as fact by a different automation blog. None of them come from Meta. When a SaaS or agency DM tool built around one of those invented ceilings starts throwing silent errors at scale, the real cause is usually a mismatch between what the product assumed and what Meta’s Graph API rate-limiting documentation actually publishes.
What Meta’s Own Rate-Limit Documentation Actually Publishes
Send API (Instagram API with Instagram Login) — text, links, reactions, stickers, per Instagram professional account.
Send API — messages containing audio or video content, per Instagram professional account.
Send API (Messenger API for Instagram surface) — text, links, reactions, stickers — a different published ceiling than the Instagram Login surface above.
Private Replies API — automated replies to comments on posts and reels only. This is the one real per-hour number Meta documents, and it does not apply to proactive DM sends.
There is no Meta-published ‘DMs per hour’ ceiling for the Send API. The limits Meta actually enforces are per-second, and they differ depending on which API surface your integration is built on.
Where Automated DM Tools Actually Get Into Trouble
Two API surfaces, two different ceilings
The Instagram API with Instagram Login and the Messenger API for Instagram are separate integration paths with separate published Send API limits (100 vs 300 calls/sec). A pacing rule built against the wrong surface’s number is wrong from day one.
The only real hourly cap is scoped to a different endpoint
750 calls/hour is real — but it governs automated Private Replies to public comments, not general outbound messaging. Treating it as a universal DM-per-hour budget is a category error that shows up as unexplained throttling well before — or well after — the real limit is hit.
Per-thread throttling with no published number
Meta’s docs state plainly that an app ‘may be rate limited if too many messages are being sent to a single thread’ — with no documented threshold. A multi-tenant SaaS tool cannot hard-code a safe pacing rule around an undefined limit.
Business Use Case throttling stacks on top
Beyond the per-second Send API gate, Instagram Platform calls are also subject to Business Use Case rate limiting (error code 80002), tracked per app-and-user pair on a rolling 24-hour window. Multi-client apps sharing infrastructure can trip this collectively even when no single client looks over the per-second limit.
The Numbers That Actually Matter
Common Misdiagnosis Patterns
- Building pacing logic around a third-party-quoted ‘200 DMs/hour’ or ‘5,000 DMs/hour’ figure that does not appear anywhere in Meta’s own documentation.
- Reading the 750-calls-per-hour Private Replies figure as a general outbound-DM ceiling, then throttling an entire send queue that was never actually close to any documented limit.
- Ignoring the API-surface difference (Instagram Login vs Messenger API for Instagram) and applying one integration’s published ceiling to the other.
- Flooding a single conversation thread and attributing the resulting throttling to an hourly cap, when it is the undocumented per-thread rule instead.
For the permission and access-tier prerequisites behind Instagram messaging automation, see the Instagram App Review Service page, the Meta Advanced Access guide, and the Instagram API cost and pricing breakdown.
Rate limits current per Meta’s official Graph API rate-limiting documentation, verified 2026-08-20 (developers.facebook.com/docs/graph-api/overview/rate-limiting). Meta may revise published limits; always confirm against the live documentation before building pacing logic.