Skip to main content

​
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 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:
  • 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: 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

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 for the OTN lifecycle.

​
Checking the conversation row

Pull the conversation to confirm the last inbound time before you pick a fix:
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 — 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