List the shopper's own renders

Publishable key (browser-safe), sent as Authorization: Bearer pk_…. This is the lower API-key tier and is sufficient for browser-safe routes that require the pk tier. Requests using a publishable key are additionally validated against the key's domain allowlist via the Origin header. Used for upload, areas, renders, polling, catalog reads, and history (history additionally requires a visitor token).

In: header

The shopper's own credential, sent alongside the API key rather than instead of it. It identifies one anonymous visitor — the owner of a set of uploads, areas and renders — and is what keeps one shopper from reading another's. It is issued by POST /images: an upload sent without this header mints a new visitor and returns visitor: { id, token, expiresAt } on the created image. Persist that token (session storage, a first-party cookie, wherever you keep shopper state) and send it back on every later pipeline call. Every successful upload — including an idempotent replay — returns the block again with a refreshed expiresAt, so an active shopper's token keeps sliding forward. Send the header on later uploads too, and they attach to the same visitor instead of starting a new one. The token is bound to one instance: a token issued under one API key's instance is rejected on another's. It expires after that instance's configured retention window (90 days by default), from which point it answers visitor_token_invalid. A secret key satisfies only the API-key tier and never bypasses this. DELETE /visitors/{id} (secret key) erases one visitor's data on demand. It does NOT revoke the token — the credential is stateless and keeps verifying until its own expiry, so the storefront should discard it; an upload that still presents it creates new data under the same vis_ id. The scheduled retention purge that will age data out automatically is still to come, so until it lands an expired token's data is retained rather than removed.

Whether it is mandatory is per-instance

Requiring the token on the pipeline operations is an instance setting (Require Visitor Token on the Public API), off by default and enabled by the Viewa team on request. With it off, an API key alone reads and writes any resource in the instance — protection is the unguessable img_/aset_/ren_ id, the same model the /file routes use. With it on, every image, area and render operation must present the token and is scoped to that shopper; a request without one is refused with visitor_token_required. Either way, a token that IS presented always scopes the request to its shopper, and a token that is present but invalid is always refused — the setting governs whether a token is demanded, never whether one is honoured. Areas and renders created without a token inherit the shopper their source image already carries, so a visitor's documents stay linked either way. GET /visitors/me/renders is the exception: it always requires the token, on every instance, because "the current visitor's renders" has no meaning without a visitor.

In: header