# 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. _Takes about 10 minutes._ ## Before you start > **Not self-serve yet** > > Facebook Messenger is marked coming soon in the product today. This page explains today's deployment-level mechanism, not a step a workspace owner completes themselves. ## 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. > **Not available for self-serve** > > The Messenger option is disabled in the UI and does not lead to a connection form. This guide documents the internal state of the code rather than providing actionable steps to connect a page. ## 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_ID` ## 4. 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. > **Missing creation route** > > While the data model supports Messenger channels, the API does not expose a way to create them. The connect_channel function ignores the type field when saving to the database, meaning a Messenger channel cannot be persisted for a specific workspace today. ## Next - [Wavy documentation](/docs/wavy) - [Meta app for WhatsApp Cloud API](/docs/wavy/guides/meta-app-for-whatsapp-cloud-api) --- Status: reviewed · reviewed by gemini-3.8-flash Author: qwen3.8-27b