Define Messenger eligibility before promising an inbox

DewEngine is researching Messenger workflows but has not selected an account contract or declared conversations, messages, media, actions, or events in the capability catalog.

Research surface only. The access contract and release decision remain open; no connector has been selected.

Talk to us ↗Read technical guides →

Capability boundary

Messenger remains an empty research capability

The provider record contains no resources, methods, or events. DewEngine must select an authorized provider contract and eligible account model before this page can describe an integration surface.

Catalog status and access: Messenger — research, undecided
Authentication: The future authorization model depends on the selected Meta product, customer application review, business assets, and user or page eligibility; none is configured today.
Resources: none declared while research remains open
Target actions: none declared while research remains open
Target events: none declared while research remains open
Limitations and failures: No connector or provider contract; No declared conversation or send method; Eligibility, messaging windows, media support, webhooks, and review requirements remain research questions
Release gates: Messenger — Select an authorized provider contract before defining capability

Product fit

Identify the support or engagement workflow first

A shared support inbox, a page conversation, and proactive outreach require different permissions and provider behavior. The research brief must state the customer job before requesting an integration surface.

Eligibility

Map the exact business and account prerequisites

Meta product selection, application review, business assets, connected pages, and user roles can change what an app may do. DewEngine needs a verified eligibility matrix rather than a generic social login promise.

Conversation model

Define participants and thread identity from provider evidence

If an authorized path is selected, the adapter must retain native conversation and participant identifiers, media references, and the page or business identity acting in the thread.

Policy state

Keep provider messaging restrictions visible

The product must know when a reply, proactive message, attachment, or automation is not permitted for the account or conversation. Those conditions need structured errors, not silent retries or undocumented suppression.

Research exit

Require a tested contract before adding methods

Resources and events should enter the catalog only after the provider path, account eligibility, consent, failure modes, webhook lifecycle, retention, and real-account tests are documented.

Research contract

Review the open integration boundary.

This shape records the questions DewEngine must resolve before selecting an access path. It is not callable, approved, or connected to a provider.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapeResearch · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No selected connector · no provider request

Questions

Before you build.

Is Messenger available through DewEngine?+

No. The capability is research-only with no selected contract, resources, methods, or events.

Does the route guarantee a shared inbox feature?+

No. It records demand while account eligibility and the authorized provider surface are still undecided.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗