Keep each Meta product boundary visible in one architecture

Meta is not one interchangeable API surface

Instagram professional features, WhatsApp Business Platform behavior, and any other Meta product have separate account eligibility, application setup, permissions, resources, messaging rules, and review. DewEngine has no approved adapter for these routes. The project rejects scraping, provider-control evasion, and anti-detection as a substitute for product approval. Each integration needs its own provider product ID and release gate even when shared infrastructure handles OAuth or callbacks.

Map business assets and roles without guessing authority

An integration plan should list the provider application, its environment, approved use case, relevant business context, eligible customer assets, app roles, redirect origins, subscribed callbacks, and reviewed permissions. Development roles may expose behavior that ordinary customers cannot use. The control plane should store stable references and current capability state rather than copying provider dashboard labels into entitlement. Every change needs an owner and evidence date.

Request product-specific permission through one safe lifecycle

Shared auth infrastructure can create short-lived intents, protect state, validate redirects, stage encrypted grants, verify provider identity, and return a connected-account ID. The allowed product and requested permissions remain specific to Instagram or WhatsApp. A grant for one surface must not silently unlock the other. Reconnect verifies the same native subject, while removal fences work and follows product-specific revocation behavior.

Reuse envelopes without merging native identities

Accounts, commands, observations, events, and webhooks may share a DewEngine envelope. Instagram profiles and conversations do not become WhatsApp contacts and business conversations merely because the provider organization is shared. Native identifiers, product type, application context, scopes, and provider extensions stay attached to each record. Customer matching across channels remains an explicit, reversible application decision with its own purpose and evidence.

Verify, identify product, then resolve the account

A single ingress layer can enforce size limits, signature or origin checks, replay protection, and safe parsing, but routing must identify the provider product before interpreting payloads. The corresponding adapter resolves the native account and event authority. Unknown assets enter quarantine, not a best-effort name match. Duplicate and delayed events cannot cross product or tenant boundaries, and missing subscriptions remain visible as capability gaps.

Approve and operate each product independently

A Meta integration release requires application review, eligible assets, least-privilege consent, method and event conformance, quotas, credential rotation, support, retention, deletion, and incident proof for the exact product. One passed Instagram read would not validate WhatsApp sending, and one WhatsApp webhook would not validate Instagram inbox history. The public catalog should show those independent states and remove stale capability when provider evidence changes.

• Use distinct connected-account product IDs and permission manifests
• Never treat shared business ownership as cross-channel user consent