Define a LinkedIn data-integration contract before selecting access

A systems guide to resource boundaries, account ownership, synchronization, events, and conformance for a connector that remains decision-gated.

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

Talk to us ↗Read technical guides →

Contract first

Separate the product API from the provider access path

A stable customer contract can describe accounts, profiles, companies, relations, chats, messages, invitations, posts, search, and jobs without pretending they are implemented. The provider adapter is a separate decision governed by authorization and conformance. DewEngine currently has only this target vocabulary for LinkedIn; the non-official session path is decision-gated and cannot be sold or invoked.

Publish capability state beside every resource and method
Return not-implemented rather than manufacturing a response

Account boundary

Scope every object to the observing account

Professional search, relationships, and conversation visibility may differ by account and product entitlement. A provider identifier without its connected-account namespace can leak data or create false global identity. Store workspace, account, provider product, external identifier, and observation time together. Customer APIs should use opaque stable IDs while retaining the source mapping inside the connector boundary.

Reject cross-account cursors and resource identifiers
Negotiate capabilities for the exact entitled product

Normalization

Unify common fields without erasing provider meaning

Profiles can share a small identity shape, and messages can share direction, sender, body, and timestamps. Provider-specific relationship state, search facets, InMail context, or job metadata belongs in versioned extensions. A unified schema should not invent unsupported fields or label a derived value as provider truth. Preserve raw observations under bounded retention for debugging and schema migration, with personal content protected from logs.

Keep canonical and provider-extension versions explicit
Document which fields are observations, derivations, or customer inputs

Synchronization

Make coverage and freshness observable

Initial backfill should be resumable, page-bounded, and honest about what it covers. Incremental observations need durable cursors or an equivalent approved mechanism, event deduplication, and periodic repair. A gap must mark the projection stale rather than empty it. Connection loss, challenge, restriction, and entitlement change are account states requiring operator or user action, not generic retry loops.

Expose last confirmed observation and current coverage
Preserve the old projection while a safe rebuild runs

Writes

Treat each action as a durable command

Message, invitation, post, or job actions would require product-specific eligibility, explicit user authority, idempotency, conservative budgets, and truthful provider outcomes. Persist the command before dispatch. Acknowledgement is distinct from recipient delivery or business success, and an ambiguous response cannot be retried blindly. Read-only integration value should not depend on enabling provider-visible writes.

Require purpose and approval for sensitive actions
Fence duplicate dispatch across retries and worker crashes

Release matrix

Conformance belongs at method and event granularity

A connector cannot inherit availability from a logo. Each product variant needs an approved access contract, exact manifest, eligible-account fixtures, schema tests, real-account smoke evidence, pacing, disconnect, deletion, and kill-switch proof. LinkedIn Classic, Recruiter, and Sales Navigator also require their own entitlement and data-sensitivity checks. Until those gates clear, documentation must remain educational and decision-gated.

Test every advertised method against the entitled product
Remove stale claims automatically when evidence expires

Questions

Before you build.

Can a unified API hide all LinkedIn product differences?+

No. It can normalize shared account and resource mechanics, but entitlement, search facets, messaging types, candidate context, and action limits may remain product-specific and must be negotiated rather than flattened away.

What should an integration return before a LinkedIn method is approved?+

Capability discovery should mark it unavailable, and an attempted call should fail with a stable not-implemented or policy-gated error. It must not return sample data as if it came from a connected provider account.

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 ↗