Define the business messaging product before integration

Keep the official business path separate from an App session

WhatsApp Business Platform is an official business-messaging product with its own onboarding, consent, template, conversation, quality, and webhook requirements. It is not equivalent to linking a personal or Business App session, reading arbitrary history, or accessing groups. DewEngine has no approved connector for either product. Scraping, control evasion, and anti-detection mechanisms are excluded, and any App-session proposal remains under a separate qualified legal and provider gate.

Verify the sender and assets that authorize it

A future connection flow should bind the workspace to the exact provider business context, application, sender identity, customer user, and granted permissions. Display numbers and names are not sufficient ownership proof. Capability discovery must show which sender is active, which actions are approved, current health, and why any method is blocked. Reconnect should preserve identity and reject substitution rather than attaching a new sender to old conversations or pending commands.

Keep opt-in evidence and suppression in the calling product

The customer application owns the lawful purpose, recipient eligibility, consent evidence, content decision, and response handling for each workflow. A transport can require a positive eligibility reference, enforce account and method budgets, and maintain suppression, but it cannot manufacture permission from a phone number or prior import. Opt-out, wrong-recipient feedback, account restriction, and human pause should make queued work ineligible immediately.

Represent provider-defined message categories explicitly

Business-initiated and reply-context messages may have different provider requirements, including approved templates or time-sensitive conversation rules. The exact current contract must be verified from provider documentation and application approval before release. A command should identify its category and required provider reference so admission can fail early. The adapter must not silently transform free-form content, misclassify a message, or retry around a provider policy rejection.

Separate submission from later recipient state

A provider acknowledgement can establish that a message was accepted or assigned a native identifier; later delivery, failure, or reading may arrive through distinct observations where supported. DewEngine's canonical state should preserve those transitions without guaranteeing every recipient event. Duplicate and delayed callbacks need idempotent application. An ambiguous timeout after dispatch remains indeterminate until safe provider reconciliation or operator review prevents a duplicate send.

Prove policy enforcement and operations together

Release requires provider business approval, eligible sender onboarding, least-privilege secrets, consent and suppression controls, template or conversation-rule enforcement, text and media fixtures, webhook verification, quota and quality feedback, ambiguous-outcome recovery, tenant isolation, support audit, export, revocation, retention, deletion, and incident shutdown. The public contract must state that it covers the official business product only. An App-session route cannot inherit this approval.

• Return stable policy and capability errors before provider dispatch
• Reserve deletion and revocation capacity even when normal sending is paused