Design one conversation model across very different account types

The planned messaging contract joins chats, attendees, messages, media, and account state without pretending that LinkedIn, WhatsApp, Instagram, Telegram, X, Messenger, and SMS share one authorization or policy model.

Decision gate closed. This access path is neither approved nor implemented; no provider action is available.

Talk to us ↗Read technical guides →

Capability boundary

Messaging coverage has several independent release gates

Telegram and official Meta surfaces have provider-authorized paths to evaluate. X, Messenger, and SMS still need a selected contract. LinkedIn, WhatsApp App, and broader Instagram account sessions cannot proceed without explicit policy approval.

Catalog status and access: Telegram user accounts — planned, official account api; WhatsApp Business Platform — research, official api; WhatsApp App accounts — decision gated, non official session; LinkedIn account products — decision gated, non official session; Instagram professional accounts — planned, official api; Broader Instagram account access — decision gated, non official session; X — research, undecided; Messenger — research, undecided; SMS — research, undecided
Authentication: The target connection flow must preserve whether authorization used official OAuth, a business-platform setup, Telegram application credentials, a QR-linked app session, or a still-undecided provider contract.
Resources: chats, groups, messages, attendees, attachments, business_conversations, templates, media, profiles, companies, relations, invitations, posts, search, jobs, conversations
Target actions: chat.list, chat.get, chat.create, message.list, message.get, message.send, message.edit, message.delete, message.react, profile.get, invitation.send
Target events: message.received, message.sent, message.read, message.edited, message.deleted, message.reaction, message.delivered, message.failed, account.status
Limitations and failures: No messaging connector is released; Available actions differ by provider and account type; Pacing, consent, quality, and session-health failures must remain provider-specific
Release gates: Telegram user accounts — Telegram application credentials, encrypted sessions, and flood-wait enforcement; WhatsApp Business Platform — Meta business verification, application review, opt-in, templates, and quality enforcement; WhatsApp App accounts — Qualified legal review and explicit product-risk approval are required before implementation or sale; LinkedIn account products — Qualified legal review and provider/product authorization are required before implementation or sale; Instagram professional accounts — Meta application review and professional-account eligibility; Broader Instagram account access — Qualified legal review and explicit product-risk approval are required before implementation or sale; X — Select an authorized provider contract before defining capability; Messenger — Select an authorized provider contract before defining capability; SMS — Select a carrier or communications API contract before defining capability

Conversation identity

Keep chats, participants, and accounts distinct

A conversation belongs to one connected account and one provider context. The normalized model can expose common participants and messages, but it must retain group membership, provider thread identifiers, and the sender identity used for each action.

Authorization

Show users which kind of account they are connecting

An official business API, a Telegram user session, and an app-linked account carry different consent and operational obligations. The connection screen and resulting account record should identify that access path rather than hiding it behind a generic channel logo.

Sending

Return command state before claiming message outcome

The target send contract accepts an account, conversation or recipient, content, and an idempotency key. Provider acceptance, delivery, read state, and reply are separate observations and should only appear when that provider supplies corresponding evidence.

Media and reactions

Negotiate capabilities per account

Text may be common, while file sizes, voice notes, reactions, edits, deletes, and group operations vary. Capability discovery should control the interface and validation so a product does not offer an action the connected account cannot perform.

Recovery

Treat pacing and reconnect states as product states

Flood waits, expired authorization, quality restrictions, provider throttling, and lost sessions need distinct errors and recovery paths. Automatic retries must stop when repeating an action could duplicate a message or violate a provider limit.

Decision-gated contract

Review the policy boundary before implementation.

This shape documents a blocked product boundary. Legal, provider, and product-risk gates must clear before implementation or sale; it is not callable.

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

Illustrative shapeDecision-gated · not callable

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

No approved connector · no provider request

Questions

Before you build.

Can an application enable every messaging provider through one connection flow?+

No. DewEngine can present a consistent outer contract, but each provider keeps its own eligibility, consent, credentials, and reconnect behavior.

Does a successful send command prove delivery?+

No. It proves only the state backed by the provider response. Delivery, read, and reply states require later provider-supported evidence.

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 ↗