Checkouts & Roles
A checkout is a time-boxed grant of access. It carries everything Bridge needs to broker one connection on a user’s behalf: who is connecting, what they’re reaching, the credentials to use, how long the grant lasts, and any guardrails (recording, command filtering, clipboard rules, and so on).
Who creates checkouts? In normal use the Britive platform creates checkouts for you when a user requests access - you don’t hand-write them. These pages document the underlying API so integrators and automation can create, inspect, and revoke checkouts directly.
The three roles
Every checkout has a role that decides what it grants:
| Role | Purpose | Connects to backends? |
|---|---|---|
| user (default) | Access - lets a person connect to one target over one protocol. | Yes |
| auditor | Oversight - lets a reviewer watch and (optionally) control sessions within a defined scope. | No |
| admin | Control plane - grants an identity full administrative powers for the checkout’s lifetime. | No |
Each role, with a worked example, is covered in Roles: user, auditor, admin.
The lifecycle
- Create -
POST /api/transactions(administrators only). See the Payload reference for every field, or jump straight to Examples by protocol. - Check in -
DELETE /api/transactions/{transaction_id}revokes the grant; a disconnect call ends any still-live session. See Checking in.
Explore
Limited (unlicensed) mode. Without a valid license,
checkout creation is limited to browser-based ssh, telnet, rdp, vnc, and
k8s; native access, live-view, session control, recording downloads, and multiple
sessions per checkout are unavailable. Install a license to unlock the full set.