Plan the complete Instagram lifecycle before coding

Start with one authorized customer outcome

A complete integration plan should begin by naming the eligible Instagram account, the person or organization granting access, the smallest useful workflow, and the provider product that permits it. DewEngine has not cleared that gate. The project excludes scraping, limit evasion, and anti-detection workarounds. Broad parity must not be treated as the default requirement; methods outside the approved customer outcome remain unavailable until separately justified and proven.

Turn the workflow into a capability matrix

List each required resource, read, write, event, content type, history depth, account variant, and failure consequence. Mark whether it is essential, optional, or replaceable by a native user task. Then map it to provider eligibility, scopes, application review, retention, and test evidence. This matrix prevents a successful authorization demo from being mistaken for a useful vertical and gives product leaders a clear place to cut unsupported breadth.

Bind consent, identity, and reconnect

A hosted flow should use a short-lived intent tied to workspace, application, user reference, allowed account product, and redirect allowlist. The callback verifies state and provider identity before storing encrypted grant material. Reconnect may update only the same provider subject. Disconnect fences work, attempts upstream revocation when supported, and starts the documented deletion lifecycle. Customer application code retains only the DewEngine account identifier, never provider secrets.

Preserve native truth under common resources

Profiles, media, conversations, and messages can share account ownership, public identifiers, timestamps, paging, and extension patterns. Writes need durable idempotency and attempt state before any provider call. Native IDs and errors remain available for reconciliation. A command accepted by the control plane is not yet a published post or delivered message; later provider evidence must advance the resource without losing uncertainty or duplicating visible effects.

Combine callbacks with bounded reconciliation

Verified provider notifications should become account-scoped observations that deduplicate safely and identify whether their payload is authoritative or only a hint. Durable checkpoints cover missed intervals, while bounded backfill exposes partial progress. Customer webhooks carry canonical event IDs and at-least-once delivery expectations. Unsupported change types and expected delay need documentation so an absent callback is not misread as evidence that no provider change occurred.

Finish support, deletion, and failure drills before launch

The release bundle should include approved application evidence, consented account fixtures, tenant isolation, quota and throttle handling, ambiguous write reconciliation, event replay, credential rotation, reconnect, support inspection, redacted telemetry, export, provider revocation, retention jobs, backup behavior, incident response, and a kill switch. OpenAPI, SDK, console, and public content must follow the resulting manifest. Anything less is a development milestone, not a complete customer integration.

• Re-run conformance when permissions, API versions, or application review changes
• Lower public capability state automatically when required evidence becomes stale