Keep social context attached to its authorized provider account

The research surface covers professional profiles, companies, posts, relationships, and search where a selected provider path permits them, with raw identifiers and policy boundaries kept visible.

Decision gate closed. This access path is neither approved nor implemented; no provider action is available.

Talk to us ↗Read technical guides →

Capability boundary

Social data access is not one approved surface

LinkedIn account access and broader Instagram sessions are decision-gated. Official Instagram professional-account work remains planned, and the X provider contract has not been selected.

Catalog status and access: LinkedIn account products — decision gated, non official session; Instagram professional accounts — planned, official api; Broader Instagram account access — decision gated, non official session; X — research, undecided
Authentication: Each resource must remain bound to the official OAuth grant or explicitly approved account session that produced it. No social-data route authorizes scraping, credential reuse, or access outside the connected user's rights.
Resources: profiles, companies, relations, invitations, posts, search, jobs, conversations, messages, media
Target actions: profile.get, company.get, relation.list, invitation.send, search.perform, post.create, job.manage, chat.list, message.list
Target events: message.received, message.sent, relation.accepted, account.status
Limitations and failures: No social-data connector is released; Fields and actions depend on account type and provider authorization; Retention, search, and automation require product-specific purpose and policy review
Release gates: LinkedIn account products — Qualified legal review and provider/product authorization are required before implementation or sale; Instagram professional accounts — Meta application review and professional-account eligibility; Broader Instagram account access — Qualified legal review and explicit product-risk approval are required before implementation or sale; X — Select an authorized provider contract before defining capability

Identity

Preserve provider IDs instead of guessing a global person

A profile, company, relationship, and conversation can refer to the same real person without sharing one reliable provider key. DewEngine's target model keeps provider identities and observed links explicit so customers can choose their own matching rules.

Profiles

Request only the context a workflow can justify

A recruiting, CRM, or inbox feature may need different fields. The connector should expose a declared field set for the authorized account and avoid turning a broad profile response into an undeclared enrichment warehouse.

Treat search as provider-specific behavior

Filters, result windows, relationship context, and pagination vary by product tier and provider. A normalized request can organize the common inputs, but raw filter support and provider limits must remain discoverable.

Posts and relationships

Keep reads separate from state-changing actions

Viewing content, publishing a post, following an account, or sending an invitation carry different user intent and provider risk. Each write needs its own permission, command record, pacing rule, and supported access path.

Data handling

Make purpose, freshness, and deletion visible

Social data changes and may become unavailable. Products need a reason for collection, a refresh policy, tenant-scoped retention, deletion behavior, and a way to distinguish provider truth from cached or inferred fields.

Decision-gated contract

Review the policy boundary before implementation.

This shape documents a blocked product boundary. Legal, provider, and product-risk gates must clear before implementation or sale; it is not callable.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapeDecision-gated · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No approved connector · no provider request

Questions

Before you build.

Does this page mean social profile extraction is available?+

No. It documents target resources across planned, research, and decision-gated providers. Availability must be checked at the specific account and method level.

Will every provider expose the same profile fields?+

No. A common resource can organize shared fields, but eligibility, field depth, search behavior, and raw identifiers remain provider-specific.

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 ↗