ReachleeInstagram restricted your account.
Here's which kind, and what happens next
Most automation vendors won't publish this page, because it means admitting restrictions happen. They do — and there are several distinct kinds with very different consequences. Knowing which one you've hit tells you whether to wait ten minutes, stop for a day, or worry seriously.
The short answer
There are three different things people call a restriction. A recoverable rate limit returns documented error codes with an estimated time in minutes until access returns, and clears on its own. A policy block returns error 368 with subcode 1404169, carries no recovery estimate, and requires stopping sends on that account entirely — we pause for 24 hours. An action block is different again: it hits your personal Instagram account rather than an API app, and it's what session-based automation tools cause. Only the third kind puts your account itself at risk.
Telling the four kinds apart
| What you see | What it is | How long | What to do |
|---|---|---|---|
| Codes 4 / 17 / 32 / 613, or 80002, with usage headers | Documented rate limit — you used your call budget | Minutes to an hour; Meta states the estimate | Wait out the reported estimate, then resume normally |
| Error 368, subcode 1404169 | Policy-level block on messaging for that account | No estimate published; assume a day | Stop all sends on that account, do not retry, review volume |
| Subcode 1772111 on a public comment reply | Meta flagged your comment-reply activity as spammy | Treat as a day | Stop posting public replies; DMs generally still work |
| Error code 2, no usage headers, no estimate | The undocumented soft clamp under sustained volume | Unpredictable | Back off hard and reduce sending rate, not just retry |
| Checkpoint, 'action blocked', or login challenge in the app | Anti-automation enforcement on your personal account | Hours to permanent, at Instagram's discretion | Stop the session-based tool entirely; this is the serious one |
Sources: Meta's Graph API rate-limiting documentation for the documented codes, and our own production error taxonomy for 1404169, 1772111 and the code-2 clamp. The bottom row is the only one that endangers your Instagram account rather than an app's API access — and official-API tools cannot cause it.
The recoverable kind: you used your budget
Meta rate-limits the Graph API by formula rather than by a flat daily number, and it tells you where you stand on every single response. The X-App-Usage header reports your app's rolling one-hour budget as percentages for call count, total time and CPU time, with throttling beginning when any field reaches 100. The X-Business-Use-Case-Usage header does the same per business account and carries the most useful field in the system: estimated_time_to_regain_access, in minutes. When you breach, you get a documented code — 4 for app-level, 17 for user-level, 32 for Pages, 613 for a custom limit, or Business Use Case codes like 80002 for Instagram. This kind of restriction is completely routine and completely recoverable. A well-built tool never even reaches it, because it watches the percentages climb and defers sends before the ceiling.
- Rolling windows, not midnight resets — budget recovers gradually as time passes
- The estimate Meta gives you is the number to sleep on; guessing longer wastes throughput, guessing shorter re-trips it
- Reachlee pauses the affected account for exactly the duration Meta reports, defaulting to 5 minutes when no estimate is given
- Seeing these occasionally on a big send is normal; seeing them constantly means your tool isn't reading the headers
The serious kind: error 368, subcode 1404169
This is the one that matters. Error 368 with subcode 1404169 is a policy-level block on messaging for that Instagram account, and it behaves differently from a rate limit in one crucial way: there is no recovery header. Meta doesn't tell you how long, doesn't tell you why beyond the policy classification, and provides nothing to wait on. In our experience the correct response is to stop sending on that account completely and leave it alone — Reachlee pauses the account for a full 24 hours and logs the event loudly rather than quietly retrying. Retrying into a policy block is actively harmful, because repeated attempts are themselves a signal. We cannot tell you the exact volume or pattern that trips it, because Meta does not publish the thresholds, and we would rather say that plainly than invent a number the way most articles on this topic do.
- No estimated_time_to_regain_access field exists on this error — there is nothing to poll
- Retrying is counterproductive and may extend the block
- Appears under sustained high-volume sending, but the threshold is unpublished and appears to vary by account
- A tool with no pause mechanism will keep hammering the API on your behalf, which is the worst possible response
The comment-reply spam signal: subcode 1772111
Separate from DMs, Instagram watches public comment replies. If your account posts public replies at a pattern Meta reads as spammy, replies start failing with subcode 1772111 and a message saying exactly that. It's worth treating as its own category because the blast radius is narrower than a messaging block: in our handling, public replies stop on that account for 24 hours while DM sending continues, since the signal is specifically about the public comment surface. The practical lesson is about repetition rather than volume. Identical reply text posted rapidly across many comments looks automated in the way Meta objects to, whereas varied replies at a human cadence don't. If you run public auto-replies alongside comment-to-DM, that's the setting worth varying first.
- Applies to public comment replies, not to DMs
- Identical text repeated rapidly is the pattern most likely to trip it
- Reachlee sets a 24-hour flag that stops public replies on the account while DMs continue
- Public auto-reply is the most expendable part of a funnel — turning it off costs almost nothing if you're near the line
The clamp Meta doesn't document
Beyond everything published, there are throttles nobody writes about. Sends can start failing with error code 2 — a generic 'service temporarily unavailable' — with no usage headers indicating any breach and no recovery estimate to wait out. We've watched this on connected accounts using the official API, under sustained high-volume sending, and the only reliable cure is to slow down rather than to retry. This is the real ceiling on Instagram DM automation, and it's the one that 'unlimited DMs' marketing pretends doesn't exist. Every tool built on the official API is subject to it. The difference between tools is whether they notice: a tool that treats code 2 as a transient error and retries immediately will walk straight into a worse state, while one that treats it as a back-off signal recovers.
Action blocks are a different problem, with a different cause
Everything above concerns an app's access to Meta's API. An action block is something else: Instagram restricting your personal account, with a checkpoint, a login challenge, an 'action blocked' banner, or in bad cases a suspension. Official-API tools cannot cause this, because they never touch your login — they hold an OAuth token scoped to specific permissions, and exceeding limits produces a rejected API request rather than a penalty on your profile. Action blocks come from session-based automation: tools that drive a logged-in Instagram session to send DMs, follow, or comment at machine speed. Those tools aren't subject to API limits, which is how they advertise unlimited sending, and they're subject to Instagram's anti-bot enforcement instead. The penalty lands on your account while the vendor keeps operating, and recovery is Instagram's decision, not a support ticket anyone can escalate.
- Official API: OAuth token, scoped permissions, errors land on the app — your profile is never the enforcement target
- Session automation: your credentials on someone else's server, and enforcement lands on you
- If you're seeing checkpoints or action blocks, identify and stop whichever tool is driving your session
- The community 'safe sending limits' spreadsheets are attempts to reverse-engineer unpublished heuristics that change without notice
What to do right now, and how to avoid the next one
Identify which kind you have before changing anything
Find the actual error your tool recorded. A documented code with a time estimate means wait. Error 368 with subcode 1404169 means stop sending on that account for the day. A checkpoint inside the Instagram app means a session-based tool is running and should be disconnected immediately. These three call for completely different responses, and guessing wrong costs you either throughput or the account.
Stop, don't retry
For anything without a recovery estimate, retrying is the one action that reliably makes it worse. Pause the automations on that account, leave it alone for 24 hours, and resume at lower volume. If your tool has no pause control, that's the more urgent problem than the block itself.
Cut volume and vary repetition when you resume
The patterns that trip policy blocks are sustained high volume and identical content repeated rapidly. Coming back at half your previous rate, with reply text that varies, addresses both. Turn off public comment auto-replies first if you run them — they're the most expendable part of the funnel and the most spam-flagged surface.
Reconnect and verify, don't assume
After any block, confirm the Instagram connection is genuinely healthy rather than just listed. A block and an expired token produce similar silence, and Instagram's long-lived tokens expire at 60 days regardless of anything else. Ruling the token out takes seconds and saves a day of misdiagnosis.
Pick a tool that pre-flights every send
The structural fix is upstream. Reachlee checks token validity, the messaging window, and live rate-limit usage before every single send, and defers rather than firing a request it expects to be rejected. That's what keeps you away from the ceiling rather than recovering from it, and it's a fair question to ask any vendor: what do you do when Meta says slow down?
Restrictions are a normal part of operating Instagram automation, and most of them are trivial — a documented rate limit with a stated recovery time that a competent tool never reaches. Two are worth real attention. A policy block, error 368 subcode 1404169, arrives with no recovery estimate and calls for stopping sends on that account rather than retrying. And an action block on your personal Instagram account is a categorically different problem caused by session-based tools that hold your login. Official-API automation cannot produce that outcome, which is the strongest practical argument for choosing it, and no amount of 'unlimited' marketing changes where the enforcement lands.
Restrictions and blocks — FAQ
How long does an Instagram automation block last?
It depends which kind. A documented rate limit tells you: the X-Business-Use-Case-Usage response header includes estimated_time_to_regain_access in minutes, and that's the number to wait on. A policy block — error 368, subcode 1404169 — publishes nothing at all, and our operating practice is to pause the account for a full 24 hours before resuming at reduced volume. An action block on your personal account from session-based automation has no published duration either and is entirely at Instagram's discretion, which is the main reason to avoid causing one.
Will using an automation tool get my Instagram account banned?
It depends entirely on how the tool works. A tool built on Meta's official Instagram API holds an OAuth token with scoped permissions and never touches your login, so exceeding a limit produces a rejected API call rather than a penalty on your profile — your account isn't the enforcement target. A tool that drives a logged-in session to send DMs at machine speed is subject to Instagram's anti-bot enforcement instead, and that does land on your account as checkpoints, action blocks and suspensions. Ask any vendor which of the two they are.
What does Instagram error 368 mean?
Error 368 with subcode 1404169 is a policy-level block on messaging for that account. Unlike a rate limit it carries no recovery estimate, so there's nothing to poll and nothing to wait on precisely — Meta simply stops accepting sends. The correct response is to stop sending on that account entirely for at least a day and resume at lower volume; retrying into it is itself a negative signal. Meta doesn't publish the thresholds that trip it, and articles quoting an exact number are guessing.
How many DMs per day is safe?
Nobody can honestly give you a number, and that includes us. Meta publishes no daily DM cap for the official API — the documented limits are per-second and per-hour technical caps plus formula-based call budgets — and the policy-level thresholds that trip blocks are unpublished and appear to vary by account. What we can say from operating experience is that sustained high volume and rapidly repeated identical content are the two patterns associated with blocks. A tool that reads Meta's usage headers and defers before a breach protects you better than any daily number would.
Can I appeal an automation restriction?
Not in any practical sense. Documented rate limits aren't appealable because they aren't punishments — they clear on their own when the rolling window recovers. Policy blocks come with no ticket path for messaging access, and the effective remedy is time plus a change in sending pattern. Action blocks on a personal account are reviewed by Instagram's own systems on their own schedule. This is why prevention matters disproportionately here: there's very little to do after the fact except wait and behave differently.
Why did my comment replies stop but DMs still work?
That's subcode 1772111, which is specifically about public comment replies being flagged as spammy rather than about messaging. The two surfaces are policed separately, so DM sending continues while public replies are blocked. Our handling sets a 24-hour flag that stops public replies on the account and leaves DMs running. The usual trigger is identical reply text posted rapidly across many comments, so varying the text or simply turning public auto-replies off is the cheapest fix.
Is a failed send the same as a restriction?
No, and conflating them causes a lot of unnecessary panic. Most failed sends are per-recipient rejections that say nothing about your account's standing: the person blocks message requests, the comment is older than 7 days, the comment already used its one reply, the recipient deleted the thread. Those are normal background noise on any post. A restriction is account-wide and sudden — everything stops at once. If your tool reports per-recipient skips as failures, a healthy account can look like a blocked one.
Does upgrading my plan raise the limits?
Not the ones that matter. The 24-hour messaging window, the one-private-reply-per-comment rule, the 7-day comment window and Meta's API budgets are platform rules that apply identically to every account and every tool regardless of what you pay anyone. A paid plan can buy you more connected accounts, more automations, or better analytics. It cannot buy messaging capacity from Meta, and a vendor implying otherwise is describing something they don't control.
Instagram