Two chatbot apps are connected to the same Facebook Page. One handles marketing, one handles support. A customer messages the Page — and both apps try to answer. Or worse: neither does, because each one assumes the other is watching. This is not a bug. It is what happens when a multi-app Messenger or Instagram integration is built without checking who actually owns the conversation thread at that moment.
Meta’s answer to this is Conversation Routing — the system that replaced the old Handover Protocol — and a specific API field, is_owner, that tells your app the one thing it needs to know before it sends a reply: is this thread actually yours to answer.
What actually changed
Handover Protocol is gone for Instagram
As of October 23, 2025, Meta no longer supports the Handover Protocol for Instagram. Every business was migrated to Conversation Routing. Meta states it is “backwards compatible with most of the Handover Protocol API and functionalities” — the word most is doing real work in that sentence; not every old integration behaves identically after the switch.
A new field: is_owner
On October 13, 2025, the Conversations API added an is_owner field for both Messenger and Instagram. It tells your app whether it is the current thread owner — but only when Conversation Routing is enabled on that Page. Request it explicitly; it is not returned by default.
Why this matters for scheduler/chatbot SaaS
Any platform that connects more than one app to the same Page or Instagram account — a marketing bot, a support bot, an AI agent, the Page Inbox itself — is exactly the scenario Conversation Routing exists to manage. Getting it wrong means duplicate replies to the same customer, or a customer who messages and simply never gets an answer from any connected app.
Thread ownership, in plain terms
At any moment, a conversation thread is either idle or active. Idle means no user-to-business message in the last 24 hours, or the previous owner released control — and in that state, only the Page's designated default application is allowed to send. Active means one specific connected app currently holds control and is expected to respond. Your app does not get to assume it is that app. It has to check.
Check ownership before replying
Call the Conversations API with the is_owner field, or send a GET request to the Page's /thread_owner endpoint for that specific user. If your app is not the owner and not the default app, Meta's own documentation is explicit that only the default application can message the user while the thread is idle.
Take, pass, release, extend, or request control
Five control flows exist: an app can pass control to a named app, release it back to idle, take it from another app if permitted, request it politely instead of taking it, or extend its own hold past the default response window. Which flow is right depends on whether the conversation is finished, escalating, or just needs more time — not on which app happened to receive the webhook first.
Respect the ad-entry thread window
Conversations that start from a Click-to-Messenger or Click-to-Instagram ad follow a separate rule: the receiving app controls the thread for 1 day from the last user message by default, extendable up to 30 days via receiving_app_control_expiration. Send an invalid value and Meta silently resets the window to 1 day — no error, just a shorter window than the one you configured.
| Date | Change |
|---|---|
| Oct 13, 2025 | is_owner field added to the Conversations API (Messenger + Instagram) |
| Oct 23, 2025 | Handover Protocol retired for Instagram; all businesses migrated to Conversation Routing |
| Sep 16, 2025 | Custom thread control window enabled for Click-to-Instagram ads |
| Jul 22, 2025 | Custom thread control window enabled for Click-to-Messenger ads |
What the API actually confirms
Everything above is drawn directly from Meta's own Conversation Routing, Conversations API, and Messenger Platform changelog pages, fetched and verified the same day this article was written. No approval turnaround, no rejection rate, and no volume figure is claimed anywhere in this article because none of it is published by Meta — those numbers would have to be invented, and we do not do that.
Where multi-app setups actually go wrong
- No default application configured. Without one, the Take Thread Control API is blocked outright, and an idle thread has no app that is allowed to message the user.
- Assuming ownership instead of checking it. A webhook notification does not mean your app currently owns the thread — it means a message arrived. Ownership is a separate, explicit check.
- Ignoring that Conversation Control actions reset the ad-entry window. Any pass, release, or take action resets a Click-to-Messenger or Click-to-Instagram thread window back to 1 day, even if a longer
receiving_app_control_expirationwas originally set. - Treating Messenger and Instagram as identical. Instagram's Conversation Routing supports Link, Campaign, and Default/Organic entry-point routing; Messenger's supports Social, Link, and Campaign — the entry-point vocabulary does not map one-to-one across the two platforms.
Where this fits for a SaaS chatbot or scheduling platform
If your product connects multiple bots, agents, or automation flows to one customer's Facebook Page or Instagram account, Conversation Routing is not optional infrastructure — it is the layer that decides whether your app is even allowed to answer a given message. Getting the permissions, webhook subscriptions, and default-application configuration right the first time is what Meta App Review is actually checking when it reviews a messaging integration.
This is the kind of setup we handle directly: reviewing an existing multi-app Messenger or Instagram integration, configuring Conversation Routing and the default application correctly, and preparing the App Review submission so reviewers see a coordinated system instead of competing bots. See our Facebook App Review service or read how we handled a similar multi-app chatbot case in Facebook Messenger Bot App Review: Why Chatbot & Automation SaaS Tools Get Rejected or Restricted. For the messaging-window rules that sit alongside this, see Meta Messaging Window & Message Tags, and for the Instagram-specific messaging permission itself, see Instagram Messaging API Approval.
This article is independent technical guidance based on Meta's official Messenger Platform documentation, verified live on the date of publication. Amandeep Singh and this website are not officially affiliated with or endorsed by Meta Platforms, Inc. Outcomes of any API integration or App Review submission depend on the specific app and cannot be promised in advance.