Skip to main content
Shared records in Databunker Pro let you create a short-lived, UUID-addressable view of a specific user’s record, optionally scoped to a subset of fields and tagged with a partner reference. They are the safe way to share a user reference across systems or with an external partner — instead of handing out a long-lived token that becomes a correlation key, you hand out a time-limited UUID that resolves to exactly the fields you authorise, and expires on its own. In conversation this pattern is sometimes called shareable identities; in the API it is Shared Records.

​
When to use shared records

Use a shared record when:
  • An external partner or downstream system needs to retrieve some fields from a specific user record, but should not be granted a long-lived token.
  • A cross-system reference is genuinely needed (e.g., sharing a customer between two business systems for a specific workflow), and you want the reference to expire automatically.
  • You want to avoid creating a deterministic, long-lived token that could become a correlation key across security domains.
For day-to-day intra-tenant lookups, use UserGet directly — shared records are for the cross-boundary or time-limited case.

​
How they work

  1. The caller invokes SharedRecordCreate, identifying the user by email / phone / login / token / custom and specifying which fields to share, an expiration (finaltime), and optionally a partner tag for the audit trail.
  2. Databunker Pro returns a recorduuid — a fresh UUID that addresses this specific shared view.
  3. The caller distributes the recorduuid to the consumer (downstream system, partner, etc.).
  4. The consumer calls SharedRecordGet with the recorduuid to retrieve the data, until expiration.
  5. After expiration, the recorduuid no longer resolves — the share ends automatically with no clean-up step required.
Every create and every retrieval generates an audit event.

​
API: Create a shared record

​
Request fields

​
Response

​
API: Retrieve a shared record

​
Request fields

​
Response

Only fields explicitly listed in the fields parameter at creation time are returned. The consumer never sees the full record.

​
Why shared records, not long-lived tokens?

Reusing the same deterministic token across multiple systems and partners turns the token into a universal correlation key — if it leaks once, an attacker can correlate everything. Shared records avoid this in three ways:
  • Time-limited. A finaltime is mandatory in practice; expired shares cannot be reused.
  • Field-limited. The fields parameter is data-minimisation by construction — partners receive only what they need.
  • Audit-attributable. The partner tag plus the audit trail attribute every retrieval to a named consumer.
  • PII Vault — how regular user tokens work.
  • Sub-accounts — multi-tenant patterns that limit deterministic-token reuse across security domains.
  • Access control — CRBAC policies and request_metadata.