How Facebook Messenger is configured today
Facebook Messenger is marked 'coming soon' in the product today. This guide explains the backend mechanism that already exists and what a self-serve connect flow would still need, rather than describing a button that does not exist yet.
1 What exists today
Facebook Messenger is currently shown as 'coming soon' in the product interface, with no active self-serve connect flow available for a workspace's own Facebook Page. The tile is visually dimmed and labeled to indicate that this integration is not yet open for standard user configuration. You cannot currently link a specific Facebook Page to your workspace through the standard onboarding steps.
2 The messaging code itself already works
The backend logic for sending messages and listing conversations is fully implemented and functional. The send_message function uses the /me/messages endpoint, which relies on the access token to identify the correct Page rather than a page ID in the URL path. The list_conversations function targets a Page's /conversations endpoint, taking the Page id from whoever calls it rather than from a stored setting. This confirms that the core messaging capabilities are ready and do not require new backend development for basic operations.
3 How a credential is resolved today
Currently, all Messenger calls resolve their access token from a single deployment-wide fallback value shared across the Meta integration family, rather than from a per-workspace credential. A deployment-wide Facebook Page id is declared alongside it, but no Messenger call reads that setting today -- conversation listing takes the Page id from whoever calls it. This means that if you were to use this functionality today, it would authenticate as the deployment's default configuration, not as your specific workspace. The environment variables META_ADS_ACCESS_TOKEN and META_PAGE_ID are the deployment-wide settings involved.
Environment variables:
META_ADS_ACCESS_TOKEN,META_PAGE_ID4 Why this isn't per-workspace yet
The data model already includes a 'messenger' type in the ChannelType enum, and the token resolution logic is prepared to check for workspace-specific credentials if they existed. However, no API route currently exists to create a channel of this type. The generic channel connection endpoint accepts a type field but does not use it to construct the database row for Messenger, leaving a gap in the persistence layer. This is the primary technical blocker preventing a per-workspace connection flow from being offered to users.
Next
Status: reviewed · reviewed by gemini-3.8-flash