Security

Keep the tenant token behind your CMS.

Authenticated Collection APIs are server-to-server. The browser talks to your CMS, and your CMS talks to Vieunite with the least-privileged credential for that environment.

Tenant server token

Send the token in the standard Bearer header from your CMS backend:

authenticated requestcURL

curl --get "https://collection.vieunite.com/v1/artworks" \
  -H "Authorization: Bearer $VIEUNITE_TENANT_TOKEN" \
  -H "Accept: application/json" \
  -H "X-Request-ID: cms-request-01HRQ2" \
  --data-urlencode "limit=20"

Never place a persistent token in Browser JavaScriptHTMLlocalStorageURLsPicker messagesapplication logs

Scopes

Request only the scopes required by your integration. The exact requirement is displayed beside every operation in the tenant API reference.

Workflow	Typical scopes
Hosted Picker only	`picker:create`, `picker:selection:redeem`, `references:resolve`
Custom catalogue UI	`artworks:read`, `collections:read`, `artists:read`, `categories:read`, `search:read`
Authenticated asset metadata	`assets:read`
Protected delivery	`assets:signed_url:create`
Local cache	`sync:read` and optionally `webhooks:manage`
Restricted content	Additional `safety:sensitive:read` or `rights:restricted:read` when approved

Picker security boundary

The Picker SDK is safe to run in a browser because it never accepts the tenant token. It asks two same-origin CMS endpoints to create and redeem temporary capabilities.

Editor is authenticatedBrowser requests a session from the CMS backend.

CMS creates the sessionBackend applies allowlisted options and its configured callback origin.

Picker uses one-time capabilitiesLaunch and runtime details stay inside the hosted flow.

CMS redeems onceBackend verifies session ownership and returns validated references with opaque rendition keys.

The SDK validates the exact Picker origin, source window, protocol version and active session before it accepts completion.

Origins and CSRF

Register the exact HTTP(S) origins that can launch a Picker. Create callback_origin from backend configuration; never trust a browser-supplied value.

Require an authenticated CMS editor for both bridge endpoints.
Apply the CMS's normal CSRF protection.
Bind each Picker session to the editor, tenant and content entry.
Allowlist selection mode, resource types, filters and expiry on the server.
Avoid logging tenant tokens or short-lived capability values.

Idempotency

Picker redemption supports Idempotency-Key. Derive a stable key from the Picker session or CMS operation so a network retry returns the first successful result instead of consuming the selection twice.

redemptioncURL

curl --request POST "https://collection.vieunite.com/v1/picker/selections/redeem" \
  -H "Authorization: Bearer $VIEUNITE_TENANT_TOKEN" \
  -H "Idempotency-Key: picker:pks_12345" \
  -H "Content-Type: application/json" \
  --data '{
  "session_id": "pks_12345",
  "selection_code": "one-time-selection-code"
}'

Do not assume every POST endpoint supports idempotency. Outbound webhooks also carry an idempotency key; webhook consumers should deduplicate on that value or event ID.

Environments and rotation

Keep test and live credentials in separate secret-manager entries and deploy them independently. A credential may be time-limited or revoked, so support overlapping credentials during rotation:

1
Issue the replacement credential with the same minimal scopes.
2
Deploy it to every CMS backend instance and verify live requests.
3
Revoke the old credential after propagation is complete.