Distinguish account connection links from conversation links

Name which kind of link the product needs

“WhatsApp link” may mean a customer-facing conversation deep link, a provider business onboarding flow, a QR or device-linking session, or simply a DewEngine account ID used by an API. Those objects carry different authority. DewEngine has released none of them. Scraped sessions, provider-control evasion, and anti-detection are excluded, and a public deep link must never be confused with permission to read or automate an account.

Bind authorization links to a short-lived intent

A future onboarding URL should represent one workspace, application, environment, customer user reference, allowed WhatsApp product, and approved return origin. It expires quickly, is consumed once, and protects state. The callback verifies provider identity before creating a connected account. Secrets, login challenges, or QR state must not appear in ordinary query strings, analytics, screenshots, support tickets, or customer database records.

Treat native open-chat links as user navigation

A link that opens a provider application for a user may carry a destination or prefilled text under the provider's supported rules. It does not prove that the recipient consented, that a message was sent, or that DewEngine can observe the resulting conversation. Products should label the handoff clearly and avoid tracking sensitive text in referral parameters. Delivery and reply state remain outside the link unless a separately authorized integration proves them.

Use opaque account IDs instead of reusable secrets

After a valid connection, customer applications should store a DewEngine public account identifier scoped to their workspace. API keys authorize the application separately; they do not become part of a shareable WhatsApp URL. Native sender and conversation identifiers remain server-side provider context. Signed short-lived links, when genuinely needed for a console action, should include audience, purpose, expiry, and single-use protection rather than embedding provider tokens.

Design for forwarding, replay, and the wrong browser

Links are copied, previewed by scanners, opened on shared devices, and forwarded to unintended people. Sensitive actions need confirmation after authentication, not bearer authority in the URL alone. Redirect targets must be allowlisted against exact origins, and errors should avoid echoing secrets. A cancelled or expired flow cannot leave a staged account usable. Audit should record safe intent and result identifiers without preserving the full URL.

Test each link class against its exact promise

Hosted connection needs provider approval, identity-safe callback, replay tests, expiry, cancellation, wrong-user handling, reconnect, revocation, and secret cleanup. Conversation deep links need current provider format verification, safe parameter handling, and copy that avoids delivery claims. Internal links need authorization and tenancy tests. None of these proves App-account messaging parity, and each should ship under a distinct name and capability record.

• Never place provider tokens or private message text in a reusable URL
• Explain whether a link authorizes, navigates, or merely identifies a resource