Exchange Pod Svid
Exchange a scheduled pod's JWT-SVID for a short-lived runtime session. The pod twin of :func:`exchange_device_assertion`: no enrollment token, no device key, no custody row. Attestation is the SVID itself, verified against the SPIRE OIDC discovery JWKS; the entry that lets SPIRE mint it is the scope control. Each SVID buys exactly one session (replay loses on the session row's unique index), so a pod fetches fresh per exchange and entry deletion stops new sessions within one SVID lifetime.
Authorization
BearerAuth Botyard API key — see /docs/authentication.
In: header
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
A scheduled pod presenting its SPIFFE JWT-SVID for a session.
The SVID is the entire request, same rule as the assertion endpoint: every identity claim lives inside the verified token, so nothing here can assert an identity the SVID does not cover.
Response Body
application/json
curl -X POST "https://example.com/v1/public/device-assertion/svid-exchange" \ -H "Content-Type: application/json" \ -d '{ "svid": "string" }'{
"session_token": "string",
"session_id": "string",
"runtime_id": "string",
"bot_id": "string",
"device_id": "string",
"gateway_url": "string",
"spiffe_id": "string",
"issued_at": "2019-08-24T14:15:22Z",
"expires_at": "2019-08-24T14:15:22Z",
"trust_tier": "user_attached",
"effect_coverage": "mediated"
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"error_code": "string",
"errors": [
{
"pointer": "string",
"detail": "string",
"type": "string"
}
],
"trace_id": "string"
}Exchange Device Assertion
Exchange a signed device assertion for a short-lived runtime session. The device registry is read live on every call and a device that is not active is refused here, before its signature is even examined. There is no cache, no TTL and no memoised lookup between that row and this decision, and there must never be one: it is the only reason a credential that never expires can still be revoked.
Redeem Device Enrollment
Redeem an enrollment token, registering this machine as the bot's device. Registering the public key and consuming the token are atomic: the token is spent by a conditional UPDATE that exactly one concurrent caller can win, and the device row is written in the same transaction, so a token is never consumed without producing the device it paid for. No session, assertion or SVID is issued here. The device credential buys only the right to *ask* for one, on every future connection, against a registry that can deny it immediately. *** THERE IS EXACTLY ONE WAY TO LEAVE HERE WITHOUT A DEVICE ROW, AND IT IS AN ERROR. *** A 2xx from this endpoint means the registry holds a live, active device for the caller — either written by this call (``201``, ``newly_enrolled``) or read back within it (``200``, the machine already being that device and offering its key). The caller may therefore treat "this call succeeded" as "a device exists server-side", which is the property an installer needs and the one it cannot establish for itself.