> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshooting: Messenger and Instagram 24-hour window closed (MESSAGING_WINDOW_CLOSED) > Fix 422 MESSAGING_WINDOW_CLOSED on Messenger and Instagram sends — Meta's 24-hour messaging window elapsed and the send did not supply an allowed messaging tag. Read the error surface, pick the right tag, or fall back to a channel whose window allows the send. # Troubleshooting: Messenger and Instagram 24-hour window closed A Messenger or Instagram send returns **422 `MESSAGING_WINDOW_CLOSED`** when Meta's 24-hour messaging window has elapsed for the conversation and the request did not carry an allowed messaging tag. The code is defined in the [Error Code Reference](/reference/error-codes) and is the most common Messenger/Instagram send blocker: the conversation simply went quiet for more than a day, and Meta treats further untagged sends as spam. This gate is enforced by Meta and relayed by Orbit. It closes only on your say-so: you pick the tag, pick `HUMAN_AGENT`, spend a one-time-notification token (Messenger only), or route the send onto another channel. ## Read the error surface The 422 envelope carries `details` that tell you which window tripped: ```json theme={null} { "error": { "code": "MESSAGING_WINDOW_CLOSED", "message": "messaging window closed for this conversation" }, "details": { "hours_since_last_inbound": 31.4, "last_inbound_at": "2026-09-05T04:12:00Z" }, "meta": { "request_id": "req_abc123", "timestamp": "2026-09-06T08:02:11Z" } } ``` * `details.hours_since_last_inbound` — how far past the 24-hour mark the send was attempted. Under \~25 this is usually a race; past a few hundred hours the recipient has simply gone quiet. * `details.last_inbound_at` — the timestamp of the recipient's last inbound message (or postback/tap, which also opens the window). Three siblings share the 24-hour idea but are different lanes: | Code | Lane | Meaning | | -------------------------------------------------------------------------- | --------------------- | -------------------------------------------------------- | | `MESSAGING_WINDOW_CLOSED` | Messenger / Instagram | Window elapsed and no messaging tag supplied (this page) | | `WHATSAPP_OUTSIDE_24H_WINDOW` | WhatsApp | Same gate on the WhatsApp channel — template required | | `WHATSAPP_RE_ENGAGEMENT_WINDOW_CLOSED` / `WHATSAPP_RE_ENGAGEMENT_REQUIRED` | WhatsApp | Meta error 131026/131047 — re-engage with a template | If you run multi-channel failover, match on `channel` in the response before choosing a fix — the Messenger/Instagram remediation below does not apply to WhatsApp, and vice versa. ## Root causes | Cause | Check | Fix | | -------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | **Tag not supplied** | The request used `messaging_type: RESPONSE` or `UPDATE`, or used `MESSAGE_TAG` with no `tag` field | Resend with `messaging_type: MESSAGE_TAG` and one of Meta's allowed tags (see below) | | **Window genuinely elapsed** | Read the conversation row and compare `last_inbound_at` against now — >24h with no inbound since | Re-open the window on the next inbound (the window re-opens on every inbound, including postbacks), or use a tag / fall to another channel | | **Conversation closed on Meta's side** | Repeated 422 even with a valid tag; `details.provider_message` on sibling `MESSAGE_SEND_FAILED` mentions blocks | The recipient blocked or restricted the page/account — suppress the recipient and never retry that thread | Allowed Meta tags on Orbit's Messenger/Instagram lanes (pick the one matching your content): * `HUMAN_AGENT` — hands the thread to a human agent; extends the window to 7 days. * `ACCOUNT_UPDATE` — account status changes. * `POST_PURCHASE_UPDATE` — order updates for a prior purchase. * `CONFIRMED_EVENT_UPDATE` — event reminders RSVP'd by the recipient. For Messenger, **one-time notification (OTN)** tokens are a one-message-per-token alternative — see the [Messenger channel page](/channels/messenger) for the OTN lifecycle. ### Checking the conversation row Pull the conversation to confirm the last inbound time before you pick a fix: ```bash theme={null} curl "https://api.orbit.devotel.io/api/v1/conversations/" \ -H "X-API-Key: $ORBIT_API_KEY" ``` Look at `last_inbound_at` (or the last message's `direction: inbound` and its timestamp). If the difference to now is under 24 hours and the send still 422s, the wrong `messaging_type` is the culprit — not the window. ## Prevention * **Tag-aware routing at send-compose time.** Before calling the send endpoint, check the conversation's `last_inbound_at`; when it is older than 24h, route the send onto `MESSAGE_TAG` (with the appropriate `tag`) or `HUMAN_AGENT` instead of `RESPONSE`. The compose check eliminates the gate instead of retrying into it. * **Template fallback onto SMS or Email.** Arm a cascade so a Messenger or Instagram primary leg escalates to SMS or Email when the window is closed. See [Cascade failover policy](/concepts/message-cascade-groups) — every hop of the cascade stays under one `message_group_id`, so the fallback run is readable as one logical message. * **Inbound-first nurture.** Postbacks, quick-reply taps, and story replies re-open the window. Structure triggers so frequent recipients get a reply event before your outbound batch runs. ## When NOT to retry The window gate is a Meta-side gate, not an Orbit retry ladder: * **Do not retry the same request body.** Without a tag (or with an unapproved tag) every retry 422s identically — the response was deterministic, not transient. * **Do not retry a `RESPONSE` send against an elapsed window.** Switch `messaging_type` first; then retry once. * **Do not treat sibling failure classes as window gates.** A 502 `MESSAGE_SEND_FAILED` with `details.provider_message` naming a token or block is a different fix (reconnect / suppress); see the runbook's escalation checklist below. ## Escalation checklist Open a ticket when the send used a valid tag, the tag matches the message content, `last_inbound_at` is current, and the 422 persists. Include: * The `request_id` from `meta` on the 422. * The `messaging_type` and `tag` exactly as sent. * `details.hours_since_last_inbound` and `details.last_inbound_at` from the error. * The conversation id and recipient PSID/IGSID (already scoped to your workspace). ## See also * [Messenger channel page](/channels/messenger) — personas, OTN tokens, and the error table this code comes from * [Instagram channel page](/channels/instagram) — `messaging_type` and the allowed tag set * [Error Code Reference](/reference/error-codes) — the `MESSAGING_WINDOW_CLOSED` row plus the WhatsApp siblings * [Troubleshooting hub](/reference/troubleshooting-hub) — every runbook in one index * [Cascade failover policy](/concepts/message-cascade-groups) — SMS/Email fallback under one message group