ReachleeInstagram error 2534037:
another app owns the conversation
This one is genuinely hard to diagnose, because it produces symptoms that look like completely different bugs. The first DM goes out, every DM after it fails, and inbound messages can appear to vanish. The cause is thread ownership — usually the inbox of the Facebook Page linked to your Instagram — and the fix isn't in your automation tool at all.
The short answer
Subcode 2534037 means your app does not own the conversation thread it's trying to send into. When an Instagram account is linked to a Facebook Page, the Page's own inbox holds conversation control by default, so every third-party app — Reachlee, ManyChat or any other — is refused until the Page hands control over. Private replies to comments are exempt, which is why the first reply lands and every DM after it fails. The fix is one Page setting on facebook.com: Advanced messaging → Connected apps → edit the app → turn on Take control of conversations.
- automated replies sent on Instagram and Facebook
- 407,105
- median time from a comment to the DM
- 2.8 s
Reachlee platform data for 28 Sep – 28 Oct 2026, across every Instagram account and Facebook Page on Reachlee (test accounts excluded). Totals marked "today" are as of 28 October 2026. Refreshed every month.
What Conversation Routing actually does
Instagram allows a professional account to connect more than one messaging application, which immediately raises a question the platform has to answer: if two apps are both listening, which one is responsible for a given conversation? Conversation Routing is Meta's answer. One app owns each thread, and ownership determines both who may send into it and which event stream the inbound messages are delivered on. An app that owns a thread receives its messages in the normal messaging stream and can reply. An app that doesn't own the thread receives those messages in a separate standby stream and is refused when it tries to send, with subcode 2534037. This is a sensible design for avoiding two bots replying to the same customer. It is also almost invisible from the outside, which is why it produces such confusing symptoms. The owner most people never think of is Meta's own: when an Instagram account is linked to a Facebook Page, the Page's inbox holds conversation control by default, so every automation tool starts out as the non-owner until the Page hands control to it.
- Ownership is per thread, assigned to exactly one connected app
- On an Instagram account linked to a Facebook Page, the Page's own inbox is the default owner
- Ownership governs both sending rights and which event stream delivers inbound messages
- Non-owning apps receive events on a standby stream rather than the primary one
- Private replies to comments are exempt, so the first message to a commenter gets through either way
- Nothing in the error surface tells you which app currently owns the thread
The symptoms, and what each really means
| What you observe | Underlying cause | Where the fix lives |
|---|---|---|
| The first DM to a commenter arrives; every DM after it fails | The linked Facebook Page's inbox owns the conversation (the default); private replies are exempt | facebook.com → the Page → Advanced messaging → Connected apps → Take control of conversations |
| Sends into a thread fail with subcode 2534037 | Your app doesn't own that thread | The linked Facebook Page's Advanced messaging settings |
| Inbound DMs appear nowhere — empty inbox, empty run log | Events are arriving on the standby stream, which your tool may not read | Tool must process standby events; ownership still needs the setting change |
| It fails for some contacts and works for others | Ownership is per thread, so older and newer threads can differ | The linked Facebook Page's Advanced messaging settings |
| It started right after connecting a helpdesk or second bot | The new app may have been given conversation control | Give control back to the app you want in the Page's settings, and disconnect what you don't use |
The second row is the one that wastes days. An empty inbox reads as a webhook or integration failure, so people re-verify their webhook, reconnect the account and rebuild automations — none of which touches the actual cause.
How we diagnosed it on live accounts
Two customers reported the same thing in September 2026: the public comment reply and the first DM went out, and every DM after it — the thank-you with the link, keyword replies, button taps — was rejected. Their configuration was correct, the automation was firing, and the accounts were properly connected, so the first hypotheses were all wrong. The distinguishing evidence was in the raw webhook payloads: the inbound messages were present, but arriving under the standby stream rather than the normal messaging stream, which meant our app was not the thread owner. In both cases the owner was the inbox of the Facebook Page linked to the Instagram account. One of them had just moved from ManyChat, which looked like the culprit; it wasn't — ManyChat had been refused by the same setting. Worth stating plainly: our first suggested fix was the wrong screen, and the customer's screenshots settled it. The setting that resolved both was the 'Take control of conversations' toggle for our app in the Page's Advanced messaging settings on facebook.com. The resolution was entirely on their side of the account, which is the single most useful thing to know about this error.
- The decisive evidence was the pattern and the event stream, not the error message
- Inbound messages were never lost: what testers typed, an email included, still reached Reachlee
- The owner was the linked Facebook Page's inbox, not another automation tool
- The fix was one toggle in the Page's settings, not a change in the automation tool, and it worked within minutes
- Our initial diagnosis was wrong; the customer's reading of their own settings was correct
How to diagnose and fix it
Check the pattern: first DM lands, the rest fail
Start here, because it's the shape of almost every case. If the comment reply and the first private reply arrive and everything after them fails, this is thread ownership. Private replies to comments are exempt from it, which is why the first one gets through. Then check whether the Instagram account is linked to a Facebook Page: if it is, that Page's inbox is the likely owner.
Distinguish 'nothing arrived' from 'arrived and was rejected'
This single distinction saves the most time. If your tool's run log is completely empty for a conversation, you're looking at a delivery-stream problem — events going to standby. If there's a log entry with a send rejection, you're looking at an ownership problem on send. Both point at 2534037, but knowing which symptom you have tells you what to look at next.
Give your tool control in the Page's settings
On facebook.com, open Settings for the Facebook Page linked to your Instagram, then Page setup → Advanced messaging → Connected apps. Edit the app (for Reachlee it's listed as Reachlee-IG) and turn on Take control of conversations. On some Pages the same choice appears as Instagram conversation routing → Default routing app. Don't look in Accounts Centre: Page links aren't shown there. This is a customer-side change — no automation vendor can make it for you, and no amount of reconnecting or rebuilding automations substitutes for it.
Disconnect what you're not using
Old automation tools left connected after a migration can also be handed control and contend for threads, so keep only the messaging apps you use. Disconnecting an old tool doesn't fix this on its own, though: the Page inbox still owns the conversations until you give control to the app you want.
Verify with a message from a fresh account
The change usually takes effect within a few minutes. Then test from a second Instagram account, ideally one that has never messaged you, so you're exercising a new thread rather than one whose ownership was already assigned. Ownership is per thread, so an existing conversation may behave differently from a new one and give you a misleading result.
Subcode 2534037 is thread ownership, and it's the hardest error in this category to diagnose because its symptoms — a first DM that works and every later one that doesn't, or inbound messages appearing nowhere at all — look nothing like a permissions problem. The cause is nearly always the Facebook Page linked to the Instagram account, whose own inbox holds conversation control by default; the evidence is that events arrive on the standby stream rather than the primary one; and the fix is the 'Take control of conversations' toggle in that Page's Advanced messaging settings rather than anything in an automation tool. If your Instagram is linked to a Page, or you've recently migrated between automation products, check that before you debug anything else.
Error 2534037 — FAQ
What does Instagram subcode 2534037 mean?
That the app attempting to send does not own the conversation thread. Instagram's Conversation Routing assigns each thread to exactly one connected messaging app, and only the owner can send into it. When the Instagram account is linked to a Facebook Page, that owner is the Page's own inbox by default. Ownership also determines delivery: a non-owning app receives that thread's inbound messages on a separate standby stream rather than the normal messaging stream. So the same underlying condition can present either as failed sends or as messages that seem never to arrive.
Why does the first DM work but every DM after it fail?
Because private replies to comments are exempt from thread ownership and regular DMs are not. The first message to a commenter is a private reply, so it gets through. Everything after it — the thank-you with the link, keyword replies, button taps, follow-ups — is a regular DM into a thread the linked Facebook Page's inbox owns, so Meta refuses it with 2534037. Giving your tool conversation control in the Page's settings fixes all of them at once.
Where is the 'Take control of conversations' setting?
On facebook.com, not in Instagram and not in Accounts Centre. Open Settings for the Facebook Page linked to your Instagram account, then Page setup → Advanced messaging → Connected apps. Edit the app you want in charge (Reachlee appears as Reachlee-IG) and turn on Take control of conversations. On some Pages the same choice is under Instagram conversation routing → Default routing app. It usually takes effect within a few minutes; test again from a second account.
Why do my inbound Instagram messages disappear completely?
Because they're being delivered on the standby stream instead of the primary messaging stream, which happens when your app doesn't own the thread. A tool that only reads the primary stream sees nothing at all, so the inbox and the run log are both empty and it looks like a webhook failure. The messages were never lost. This is why people spend days re-verifying webhooks and reconnecting accounts without making any progress — the delivery path changed, not the delivery itself.
Can my automation tool fix this for me?
Only partly. A tool can process standby events, which at least means it can see the messages and give you the evidence to diagnose the problem — that's how we identified it on live accounts. But thread ownership is decided in the conversation settings of the Facebook Page linked to your Instagram, and no vendor can change those on your behalf. So the diagnosis can come from your tool while the fix has to come from you, in the Page's Advanced messaging settings.
Does having two automation tools connected cause this?
It can, but it's not the usual cause. Most often no second tool is involved: the Instagram account is linked to a Facebook Page, and the Page's own inbox holds the conversations by default, so every third-party app is refused until the Page hands control over. That's why people who just left ManyChat often blame it — ManyChat was refused by the same setting. Another app can also be given control, such as a helpdesk or an old tool never disconnected, so keep only the apps you use. Either way the fix is the same Page setting: give conversation control to the app you want.
Why does it only affect some conversations?
Because ownership is assigned per thread rather than per account. Threads that existed before a second app was connected may be owned differently from threads created afterwards, so sends can succeed for long-standing contacts and fail for new ones, or the reverse. This is also why testing with an existing conversation after changing the setting can mislead you — use an Instagram account that has never messaged you so you're exercising a fresh thread.
Is this the same as being rate limited or restricted?
No. Rate limits arrive as documented codes such as 4, 17, 32 or 613, with usage headers and an estimated time until access returns, and a policy block is error 368 with subcode 1404169 and no recovery estimate at all. Those are account-level and stop everything at once. 2534037 is a routing and permissions condition affecting specific threads, carries no implication about your account's standing with Meta, and won't resolve by waiting.
Instagram