Skip to main content
Read and delete only. Sessions are created as a side effect of a checkout run that logged in — there is no POST. Concepts in Buyer sessions.

​
List

Success: 200.
​
string
Optional. Omit to list every session for the tenant — or, on a subject-bound key, every session belonging to that one end user.
Sessions have no subject of their own. They belong to a buyer profile, and the profile is what carries the identity, so isolation is applied by joining to it: one place holding “who is this” rather than two places to forget to filter. A bound key sees only the sessions of its own end user’s profiles, and DELETE on anyone else’s is a 404.
Not paginated. Ordered by updatedAt descending.
​
array
Metadata only. No endpoint returns the cookie blob.
​
string
The registrable domain the session belongs to. Sessions are keyed on (tenant, buyerProfileId, merchantDomain) — one per merchant per profile.
​
string | null
Stamped when a session is loaded into a run. null if it has been stored but never reused.
​
boolean
false means session storage is not configured on this deployment. sessions is then always [] and runs proceed logged out. Check this before building UI around the feature.

​
Revoke

Success: 200.
A hard delete, not a revocation timestamp — the row is the credential, so the right thing to do with it is destroy it. 404 Session not found if it does not exist or belongs to another tenant.
This stops us using the session. It does not sign the buyer out at the merchant. If a session may have been misused, delete it here and end it from the merchant’s own account security page.

​
No create endpoint

Sessions come into existence only through a checkout run: a credentials user action logs in, and the resulting cookies are captured immediately afterwards while the browser is still warm. There is no way to upload cookies directly, and that is deliberate — the vault stores what a login it supervised produced, scoped to that merchant’s domains, and nothing else.