vault:// reference and never see the secret. The REST surface below is read-and-status only: no route ever returns a secret, a code, or a connect token, not even to the caller that created it. Credentials are created, edited and deleted from the dashboard, or captured from the person who owns the login through a connect link. Second-factor codes come in through verifications, and a credential whose policy is approval_required pauses the login until a member approves it in the dashboard.
GET /v1/credentials
List the credentials stored for your organisation, metadata only. Auth: Bearer API key. No body. Response:
With nothing stored:
login so an agent knows whether a credential for the host already exists instead of asking a person for a password.
GET /v1/credentials/{cred_id}
One credential’s metadata (the fields listed above). Auth: Bearer API key. Errors: 404credential not found for an unknown or malformed id, or another organisation’s (not distinguished); 401.
DELETE /v1/credentials/{cred_id}
Revoke a credential everywhere: the row is deleted first, then every live session that used it is signed out and the cookies captured from its logins are forgotten. Auth: Bearer API key. Response:{"ok": true, "id": "<cred_id>", ...} plus counts of what the revocation reached (sessions touched, cookie jars deleted).
Errors: 404 credential not found; 401.
POST /v1/credentials/connect
Mint a one-time capture link for a host. You post the link to the person who owns the login; they open it, enter the username and password (or an authenticator key) on a page served by Tilion, and the credential lands in your organisation’s vault pinned to that host. The token is in the URL only: it is returned once and never stored or shown again. Auth: Bearer API key. The key must belong to an organisation account (one created through the dashboard sign-up). Request:
Response:
connect_id, connect_url (the link to post), host, expires_at. A link lives 15 minutes and completes once.
Errors:
Free. The capture page itself (
GET /connect/{token}) needs no API key; it is plain HTML, never echoes what was typed, and answers 404 for a link that is unknown, used, expired or voided. A link minted for one dashboard user and opened by another is voided (403).
GET /v1/credentials/connect/{connect_id}
Poll a link you minted. Status only. Auth: Bearer API key (the same organisation that minted it). Response:connect_id, status (pending, completed, expired, voided), host, credential_id (set once completed; use it with GET /v1/credentials to find the path), expires_at, session_id.
Errors: 404 connect link not found for an unknown id or another organisation’s link (the two are not distinguished).
GET /v1/verifications
The pending second-factor verifications for your organisation, so an agent or a dashboard can show the inbox. Auth: Bearer API key. Response:verifications[], each with the fields of GET /v1/verifications/{id} below. Expired rows are dropped before the list is answered.
GET /v1/verifications/{verification_id}
Poll one verification. The code is never returned. Auth: Bearer API key. Response:
Errors: 404
verification not found for an unknown id or another organisation’s row.
POST /v1/verifications/{verification_id}/code
Submit the one-time code for a pending verification. A login that stopped at a second factor claims the code exactly once and types it; the code is stored encrypted and never returned. Auth: Bearer API key. Request:
Response:
{"id": "<verification_id>", "status": "resolved"}.
Errors:
GET /v1/approvals/{approval_id}
Poll a login approval. When alogin task uses a credential whose policy is approval_required, the task answers at once with ok: false, status: "awaiting_approval" and an approval_id (in async_mode, the same fields appear in the job’s result). A member of your organisation approves or denies it in the dashboard, which can show the paused session through live_view_url. You poll here, and when the status is approved you call POST /v1/agent again with the same login parameters plus approval_id; the approval is spent by that call, is bound to the credential and session it was granted for, and expires if unused.
Auth: Bearer API key (the organisation that owns the approval). Deciding is a dashboard action.
Response:
Errors: 404
approval not found for an unknown or malformed id, or another organisation’s approval. A resume with an approval that is not approved, is for another credential or session, or has expired is refused by POST /v1/agent with 409 approval not usable: <why>.
Free. Two concurrent resumes with the same approval cannot both succeed; the second sees consumed.