Map WhatsApp products before defining one API

WhatsApp is not one undifferentiated account product

The official business platform and a proposed QR-linked App account offer different identities, conversations, histories, group behavior, rules, and risks. DewEngine has implemented neither. Official access needs provider business approval and exact policy conformance; App-session access remains separately decision-gated. The project rejects scraping, enforcement evasion, concealment of automation, and anti-detection. Documentation and capability discovery must always name the product.

Attach every resource to its authorized sender identity

A connected record should identify workspace, provider product, native business or account reference, health, granted capabilities, application context, and evidence version. The customer user and external contact remain separate identities. Reconnect must prove the same provider subject before replacing secrets. If a sender, business asset, or App identity changes, it becomes a new account rather than inheriting old messages or queued actions by display-number similarity.

Keep business conversations and App chats distinct

A common envelope can cover conversations, participants, messages, attachments, timestamps, and native identifiers. Provider-product extensions still determine template references, group membership, history coverage, delivery observations, and supported actions. A field absent from the official business contract must not be implied by a generic WhatsApp response. Cross-product migration or matching is a customer decision with explicit evidence, not an automatic merge based on a phone number.

Admit messages through policy and capability checks

A send request needs a specific connected account, native recipient or conversation, content type, customer eligibility decision, and idempotency key. Admission and worker dispatch both check capability, account health, provider rules, suppression, and pacing. The result distinguishes accepted, acknowledged, failed, suppressed, and indeterminate states. Unsupported group, message, template, or reply behavior should fail before any provider action rather than being silently approximated.

Normalize provider observations without promising coverage

Inbound messages, sender status, and delivery-related updates can become canonical events only when the chosen product exposes them and their origin is verified. Duplicate callbacks, late order, unknown senders, and retired accounts require safe handling. The manifest should state whether each event is authoritative or a hint. A lack of notification cannot be treated as proof that a person did not reply, receive, or read a message.

Advance products independently through their gates

An official business connector needs provider approval, consent controls, policy enforcement, sender conformance, webhooks, quota handling, support, privacy, and deletion. An App-account connector would additionally require qualified contractual and legal clearance plus a separate risk decision before implementation or sale. Neither can borrow evidence from the other. Site routes, SDK methods, and product pricing should remain absent until the relevant manifest reaches a releasable state.

• Name the WhatsApp product in every account, method, event, and error
• Keep research routes from appearing as capability discovery results