Plan WhatsApp integration from product choice through deletion

Choose official business access or hold the App path

The first integration decision is which WhatsApp product can lawfully and contractually support the customer outcome. Official business access has explicit provider onboarding and messaging constraints. App-linked history and group behavior are a separate unresolved risk boundary. DewEngine has released neither and rejects scraping, control evasion, anti-detection, or concealment of automation. Each product advances only through its own written gate.

List required resources and acceptable fallbacks

The brief should enumerate sender identity, recipient or chat type, history, messages, media, groups if relevant, templates or reply context, events, delivery observations, and administrative needs. Mark every item essential, optional, or replaceable by a native user action. Mapping those requirements to provider-product support prevents a smooth login demo from being mistaken for a complete workflow and gives decision-makers a safe way to remove unsupported scope.

Bind account identity, permission, and application context

A future hosted flow starts with a short-lived workspace intent and names the selected WhatsApp product. The callback verifies state, provider identity, and eligible sender before encrypted credential staging. Capability discovery reports current methods and events. Reconnect updates only the same native identity. A customer application stores an opaque DewEngine account ID, while provider tokens, QR state, login challenges, and secrets remain outside its code and support channels.

Put durable policy checks before every provider action

Message commands carry recipient purpose, customer approval, content category, account, and idempotency key. Admission checks tenancy, permission, capability, suppression, and policy; workers recheck health and budgets after leasing. Provider attempts preserve acknowledgement and uncertainty. Inbound observations deduplicate and can stop queued work. The platform must not retry an ambiguous send, reinterpret a provider rejection, or let one account's cooldown block unrelated tenants.

Design support and incident controls before volume

Operators need safe request and command IDs, account health, provider attempt phases, webhook history, throttle reasons, sync checkpoints, and reversible holds without routine access to private bodies or secrets. Kill switches should stop new dispatch while preserving reconciliation, revocation, and deletion lanes. Monitoring separates queue lag, provider latency, event lag, and outgoing delivery. Fault tests cover disconnects, duplicate callbacks, expired grants, worker crashes, and provider degradation.

Offboarding and public truth finish the integration

A releasable vertical needs approved provider access, consented conformance, tenant isolation, secret rotation, exact methods and events, support, export, recipient suppression, retention, upstream revocation where supported, data deletion, backup expiry evidence, and incident drills. Public capability state, SDKs, console, legal text, privacy information, and any commercial offer must match that product. Anything still decision-gated remains absent from runtime discovery.

• Test identity substitution and in-flight work during reconnect and delete
• Preserve revocation and deletion lanes when normal provider dispatch is disabled