Define post reads separately from post creation

A resource-model guide that explains why a posts target and post.create method do not prove listing, retrieval, comments, reactions, or a released LinkedIn connector.

Educational research only. LinkedIn account access remains decision-gated. No DewEngine LinkedIn connector is approved or implemented.

Talk to us ↗Read technical guides →

Catalog reading

The current target does not declare a post read method

DewEngine's LinkedIn entry names posts as a target resource and post.create as a target action. It does not list post.get, post.list, comments, reactions, media retrieval, or post events. None of those targets is implemented because the entire provider remains decision-gated. A public guide must not turn a resource noun into an implied data-retrieval API.

Require explicit read operations in the manifest
Return unsupported instead of constructing data from page scraping

Use-case scope

Specify which posts and why

A product may want to show the connected account owner's recent posts, associate a customer-selected post with a campaign, or archive company-authored content under a retention policy. These are narrower than retrieving arbitrary public activity. Name the subject, author relationship, time range, account, purpose, and destination. Avoid open-ended surveillance or bulk copying merely because content is visible.

Tie post access to a user-visible feature
Keep an alternative link-only workflow when copying is not authorized

Post schema

Model authorship, content, media, and metrics distinctly

A post resource could need provider-scoped identity, author type, text, creation observation, media references, and source URL. Comments, reactions, reshares, and metrics are separate resources or observations with different permissions and freshness. Do not flatten a mutable count into a permanent truth or imply that missing engagement means zero when the approved contract did not provide it.

Version provider extensions for content variants
Store derived analytics outside the provider observation

Synchronization

Handle mutable and deleted content carefully

Posts can change or become inaccessible. A sync design needs observed versions, deduplication, bounded pagination, partial coverage, and a clear deletion or tombstone contract. A failed refresh does not prove deletion. Customer annotations and campaign associations should survive separately when policy permits, while copied post content follows source retention, correction, and deletion requirements.

Keep last-confirmed time and current access state
Do not erase customer workflow because a source read failed

Publishing distinction

Do not let a read design imply post creation

Creating a post acts through a professional identity and requires final-content approval, sender authority, media validation, idempotency, account health, action budgets, and truthful acknowledgement. Reading approved content and publishing new content should have independent capability switches. An analytics feature should not receive write scope, and a publishing tool should not automatically archive unrelated posts.

Issue separate read and publish permissions
Bind publication approval to exact content and acting identity

Evidence plan

Add read methods only after exact authorization

A future release needs provider and legal approval, eligible author and account types, read schemas, pagination, edit and deletion behavior, media rules, throttling, restriction, tenant isolation, retention, export, and consented conformance. Post creation requires its own lost-response and duplicate tests. Until these rows exist in the manifest, DewEngine cannot say it retrieves LinkedIn posts.

Test author and account substitutions
Publish unsupported comment and engagement behavior explicitly

Questions

Before you build.

Does the posts resource in capabilities.json mean DewEngine can list posts?+

No. The catalog expresses target architecture, and it declares no post read method. The provider has no implementation or conformance evidence, so listing posts is not a DewEngine capability.

Should a missing post during refresh be deleted from the customer product?+

Not without a proven deletion signal. Mark the source observation inaccessible or stale, apply the content-retention policy, and keep customer-owned annotations or associations separate from copied post content.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗