Add professional profile context without making it your identity system

A platform-design guide to external identity links, partial profile projections, field ownership, developer contracts, and privacy within a decision-gated connector plan.

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

Talk to us ↗Read technical guides →

Platform role

Profile context should enrich an existing user task

A developer platform might display a customer-confirmed professional identity beside a CRM contact, candidate, speaker, or partner record. It should not make LinkedIn the login identity, global person registry, or authority for customer relationships. DewEngine's profile target is unimplemented and decision-gated, so a platform must define the same experience for manual links or another authorized source.

Keep the host application's person ID authoritative
Treat provider context as optional and removable

External identity

Namespace every provider reference

Store an opaque DewEngine resource ID externally and retain provider, connected account, external identifier, and observation version inside the integration boundary. Names, slugs, and profile URLs can change and should not serve as cross-tenant keys. If two customer records claim the same observed profile, expose a merge suggestion within that workspace; never use it to join customers or reveal another tenant's data.

Enforce workspace ownership on every lookup
Preserve evidence for manual link, unlink, merge, and split

API shape

Return small canonical fields plus typed extensions

A stable resource could include source identity, display label, observed time, coverage, and selected normalized professional context. Product-specific fields belong in versioned provider extensions. Optional fields should remain optional; unavailable values must not be filled with guesses. A response should identify stale or partial observations so an application can render uncertainty instead of presenting a polished but false full profile.

Version canonical and provider-specific schemas independently
Expose field provenance to authorized developer clients

Embedding

Protect profile data in UI and support tools

A host application should request only fields needed for the current screen and respect its own roles. Avoid placing copied profile text in URL parameters, analytics events, exception traces, or generic support exports. If a user opens source context, make the origin and freshness visible. Server-side caches must carry tenant scope and a bounded retention policy rather than becoming an untracked mirror.

Redact personal fields from telemetry by default
Require explicit permission for bulk export or secondary indexing

Change handling

Reconcile observations without erasing customer truth

A role or company change can create a new observation and an optional update proposal. The platform should preserve customer-entered notes, historical associations, consent, and workflow state. An inaccessible profile is not proof that the person or customer record should be deleted. Mark the provider projection stale, retain the last confirmed evidence under policy, and offer correction or unlink.

Apply field-level source precedence
Keep history when it serves a documented customer purpose

Developer readiness

Ship only a field set backed by current evidence

Readiness requires approved access, provider or partner authorization, exact eligible account products, fixtures for partial and changed records, tenant-isolation tests, caching and retention rules, correction, export, deletion, rate protection, and consented real-account conformance. Generated SDKs and documentation must match the capability manifest. No client method should appear merely because the route or type exists.

Contract-test optional fields and unknown states
Remove stale generated docs when a capability is gated

Questions

Before you build.

Should a SaaS use a LinkedIn profile ID as its primary person key?+

No. Use the SaaS's tenant-owned person key and attach source-scoped external identities. That supports manual records, multiple sources, unlinking, product changes, and a functioning product when LinkedIn access is unavailable.

Can profile text be copied into application logs for debugging?+

It should not. Log safe identifiers, schema versions, field presence, request correlation, and error classes. Personal content belongs only in protected data stores with defined access, retention, and deletion.

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 ↗