Replace the full-profile promise with a proven field contract

A field-level architecture for profile retrieval that makes account scope, partial coverage, source provenance, refresh, and unsupported data explicit.

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

Talk to us ↗Read technical guides →

Wording matters

Full profile is not a stable technical unit

Different account products, relationships, permissions, and moments can expose different professional context. Calling any response full implies completeness that the integration may not prove. DewEngine lists profile.get only as a target under a decision-gated LinkedIn provider. There is no approved adapter, field schema, or real-account conformance, so the honest design begins with an explicit optional field set.

Define completeness per versioned contract if the term is ever used
Show coverage and observed time in every response

Lookup input

Resolve identifiers inside the authorized account scope

An application may begin with an opaque DewEngine ID, a customer-confirmed external reference, or a profile URL. The adapter must validate workspace and connected-account ownership before resolving anything. Names and URLs are mutable hints, not global identity keys. Do not crawl a supplied URL or replay private requests when the approved profile method cannot resolve it.

Namespace provider identity by account and product
Return a gated or not-found state without leaking visibility

Response schema

Use field provenance and absence reasons

Each observed value can carry source, timestamp, and transformation version. Optional fields need enough metadata to distinguish not requested, unsupported, redacted, inaccessible, and absent. Customer-entered contact data and derived classifications sit outside the provider object. In particular, do not invent email, phone, protected traits, or personal intent from professional text.

Keep provider extensions typed and versioned
Prevent derived fields from appearing under provider provenance

Caching

Cache narrow projections with an expiry purpose

Profile context may be reused within one tenant feature, but the cache must retain account scope, observation time, schema version, and retention. A later failed refresh should mark data stale rather than erase it. Cross-tenant caching or global identity graphs can reveal another customer's observations. Purge derived search indexes and previews when the underlying record expires or is deleted.

Use different freshness rules for different fields
Never cache provider authorization in the profile response layer

Customer update

Propose changes instead of overwriting CRM history

A refreshed employer or role can inform the user, while the CRM keeps ownership of account stage, relationship notes, consent, and manually verified fields. Apply source precedence per field and make conflicts reviewable. If a profile becomes unavailable, retain permitted customer history and the last confirmed observation; inaccessibility does not prove that the person ceased to exist.

Support accept, reject, unlink, and restore
Record which evidence justified an automated low-risk update

Conformance gate

Prove every field and failure state

Release requires legal and provider approval, exact entitled account products, fixtures for each advertised field, partial and redacted responses, changed identities, throttling, revoked sessions, restriction, cursor or ID substitution, privacy rights, retention, and deletion. Documentation and SDK types must come from the same current manifest. Until then, DewEngine cannot promise full LinkedIn profile retrieval.

Test both field presence and legitimate omission
Retire claims when source evidence becomes stale

Questions

Before you build.

What should a full-profile endpoint return when one field is unavailable?+

That question shows why the label is unsafe. Use a versioned partial profile contract with optional fields and coverage metadata, then state precisely what was observed and why a value may be unavailable.

Can an old profile projection remain after the account disconnects?+

Only according to the documented customer purpose and retention policy. It must be marked last-known or stale, future collection must stop, and deletion or subject requests must locate every retained copy.

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 ↗