Model Instagram posts across their full lifecycle

Define full as the exact authorized lifecycle

Post integration can mean reading customer-owned media, publishing new content, observing comments, updating metadata, or deleting an item. Those outcomes may not share the same permission or provider support. DewEngine has no released post adapter and will not use scraping, control evasion, or anti-detection to imitate missing methods. The approved account product and application review must decide which lifecycle steps can enter a capability manifest.

Keep media, post, and container state distinct

A future schema may need separate objects for uploaded media, provider-side preparation, the visible post, multi-item relationships, captions, and derived observations. Each resource retains the connected account, native identifier, timestamps, content type, and provider extensions. A client should not infer visibility from the existence of an upload record. Stable DewEngine IDs help application references while native IDs remain necessary for support and reconciliation.

Expose paging, freshness, and ownership limits

Post lists should declare whose content is in scope, which fields are requested, how pages are ordered, and when observations were refreshed. An empty list after authorization loss is not an authoritative account history. Comments, reactions, insights, or public discovery should appear as separate capabilities rather than implicit children of a post read. Cursors stay bound to the workspace and account so one connection cannot query another's result set.

Use durable commands for create, change, and delete

Every provider-visible operation needs its own permission, role decision, idempotency boundary, and provider attempt. Create may involve media preparation before publication; update and delete may have different support and failure modes. A timeout after submission remains indeterminate until safe reconciliation. The API should never claim that deletion completed across provider systems, DewEngine storage, derived indexes, and backups based on one successful endpoint response.

Apply observations without overwriting user drafts

Provider events or scheduled reconciliation may show that a post became visible, failed moderation, changed, or disappeared. Those observations should update a provider-state projection while preserving the customer's source draft and approval record. Duplicate or delayed events cannot restart publication. If an event type is unavailable, the product should disclose polling lag or manual refresh rather than advertising instant state changes.

Test each advertised lifecycle edge independently

Release proof covers eligible accounts, approved permissions, supported media combinations, list and get paging, publication stages, idempotent retries, ambiguous outcomes, update and deletion where promised, event gaps, moderation responses, quota handling, disconnect, export, retention, and incident shutdown. Real-account fixtures must establish what users see after every transition. The site and SDK then expose only the passed edges, not the aspirational word “full.”

• Use distinct capability flags for read, create, update, delete, and event coverage
• Retain customer draft ownership separately from the provider's resulting object