Messenger Setup

Connect an authorized Facebook Page to the intended Kravos.ai agent. Signed Page-destination identity selects the tenant and connection; a customer's Page-scoped ID never chooses another tenant or a deployment-wide token.

Before You Start

The deployment's Meta channels system setting must be enabled to expose Messenger and Page-linked Instagram setup; sandbox organizations receive feature availability automatically. This does not grant Meta permissions or production approval. Hiding setup leaves existing active processing, inbox history, authorized disable/revoke operations, and compliance callbacks working.

• Use a Meta account with the required management access to the intended Page.
• Confirm the deployment's public HTTPS origin, signed webhook endpoint, supported Graph version, schema, and worker/runtime readiness.
• Have the deployment operator verify the exact Facebook Login for Business configuration, registered redirect, consent wording, and required Page grants.
• Confirm the intended Conversation Routing/Handover setup and the human inbox that will handle escalation.

The operator creates a genuine matching MESSENGER_LOGIN_REVIEW only after consent and deployed logging-safety checks pass. A review record is evidence, not a feature-enable shortcut. Tokens and authorization codes must not appear in callback, proxy, application, collector, or provider-egress logs.

Connect From The Agent

1. Open the intended agent's Channels page and start Messenger consent.
2. Authorize access through Meta and return to the same initiating workspace and agent.
3. Select the Page you intend this agent to serve. Verify the Page and agent before confirming the connection.
4. Follow the separate subscription, readiness, and activation actions shown by the connection. Saving does not implicitly prove all of them.
5. Test with authorized development assets, then complete permission-level review and non-role own-Page acceptance before production use.

Cancel/deny and expired attempts must remain truthful. Start fresh consent rather than reusing a callback URL or another tab's authorization result. Page replacement, reconnect, and revocation must retain historical conversation ownership rather than moving old work to the newly selected Page.

Do not create a legacy ChannelConfig as a substitute for the connection flow. Deployment-wide tokens are restricted to the established legacy compatibility path, not fallback credentials for a failed customer connection.

Webhook And Message Processing

The public webhook endpoint is:

https://your-web-app.example.com/api/webhooks/messenger

The deployment operator registers the verification token and appropriate app/Page subscriptions without exposing secret values. Kravos.ai verifies POST signatures against the original request bytes, resolves the signed Page destination, records durable admission, and publishes a queue wake-up.

Supported text and media use the protected channel processing path. Unsupported or unavailable attachments remain explicit. Outbound replies use the credential belonging to the original connection and are checked against lifecycle, assignment, messaging-window, and ordering rules before dispatch.

A send response or correlated own echo establishes Accepted, not recipient delivery. Supported delivery/read callbacks establish their own evidence. Missing callbacks and request timeouts do not establish rejection.

Human Replies And Routing

Own-send echoes and manual replies are different events. Kravos.ai correlates its own outbound provider IDs so an AI echo does not trigger takeover. A verified manual Page reply can transition the matching conversation to human ownership and fence stale unsent AI output.

Provider thread ownership, Conversation Routing/Handover events, standby handling, and local assignment must be verified together. Do not assume that merely subscribing to echoes makes every handoff race safe, or that every is_echo event is a human reply.

Verify The Whole Journey

1. Send an authorized customer message to the selected Page and verify the correct agent/conversation receives it.
2. Observe one logical turn, canonical reply, outbound intent, and provider acceptance separately from delivery/read receipts.
3. Verify an own AI echo does not cause takeover.
4. Exercise a manual Page reply and the approved escalation/routing path; verify stale unsent AI work does not dispatch afterward.
5. Exercise supported attachments, window policy, Page replacement/reconnect, revocation, and late callbacks within the approved test scope.
6. Record separate non-role customer acceptance with the customer's own Page before production activation.

Troubleshooting

• Consent or selection fails: verify the reviewed configuration, Page access/grants, attempt expiry, initiating agent, and clean return URL. Do not paste tokens or codes into support messages.
• Inbound not routed: inspect the signed Page destination and connection status; do not route by an existing customer conversation across tenants.
• Unexpected AI reply after takeover: inspect the original operation, assignment version, verified echo classification, and provider routing state.
• Unknown send: use the audited reconciliation flow. Resolve without resend or satisfy the existing retry authorization contract; never assume timeout means rejection.
• Profile unavailable: optional profile enrichment is separate from messaging authorization and must not cause cross-Page credential fallback.
• Deletion request: follow the public Privacy Policy; revocation and disconnect do not themselves erase retained data.