Represent Instagram messages as sourced observations

Message modeling follows authorized conversation access

A detailed message schema is useful only after an approved Instagram product defines which conversations and events the application may observe. DewEngine has not reached that point. Missing history or fields will not be collected through scraping or provider-control evasion; anti-detection is rejected. Each exposed attribute needs a customer purpose, eligible account, permission basis, real-account fixture, and retention decision before it becomes part of a public contract.

Keep provider fact separate from product annotation

A normalized message could include a DewEngine ID, connected account, native message and thread identifiers, direction, observed sender, provider creation time, content type, reply relationship, and current observation state. Customer tags, assignments, summaries, or CRM links belong in application-owned fields. They should not overwrite the raw provenance. Absent provider data remains absent rather than being inferred from thread order, display names, or neighboring message content.

Limit custody to what the workflow needs

Text, shared media, files, voice content, reactions, and unsupported objects need explicit type handling. The adapter should reject excessive size before allocation, stream authorized files through encrypted object storage where necessary, and avoid placing bodies or download URLs in routine logs. Customer exports and support views require separate permissions. A placeholder for an unavailable attachment is more truthful than silently dropping the message or claiming a complete transcript.

Append new evidence instead of rewriting history blindly

If the approved provider product exposes edits or removals, the connector should store the observation and update the canonical projection without erasing audit context needed for support. An unavailable message after a failed read is not necessarily deleted. Customer-requested erasure, provider-side removal, account disconnect, retention expiry, and backup expiry are distinct causes with different evidence. Public status should name what completed and what remains pending.

Scope lists and cursors to one account and purpose

Message listing should require the exact account or conversation boundary, bounded time or page controls, and opaque cursors encrypted or signed against substitution. Full-text search, if ever offered, would need a separate purpose, index lifecycle, permission model, and deletion proof. Default support and analytics paths should use metadata rather than content. A partial sync must signal its checkpoint so callers do not treat results as complete history.

Validate message fidelity under difficult provider states

Acceptance requires approved conversation access, native identifier stability, paging, history boundaries, every advertised content type, attachment limits, reply links, duplicate callbacks, edits and deletions where supported, permission loss, export, retention, redaction, and tenant isolation against consented accounts. Fixtures should include unsupported objects and delayed events. Until those cases pass, the model is a data-design exercise and not an Instagram message API.

• Expose partial transcript coverage and last successful observation to callers
• Keep content unavailable to billing, metrics, and ordinary operational search