API Reference

API Reference

All endpoints are relative to the Vault base URL and are prefixed with /api/v1.

There are two authentication mechanisms across the API:

  • Client authorization — the request body carries the client’s clientId and clientSecret. Used for endpoints where the client acts on its own behalf.
  • User authorization — the Authorization: Bearer <access_token> header carries a user’s token. Used for endpoints where the acting party is the user themselves.

Fetch the keyset

Retrieves the public keys of the availability the client is linked to. Fetch once at startup, cache, and use the keys to verify access tokens locally.

Property Value
Method POST
Path /api/v1/client/keyset

Body parameters:

Parameter Required Description
clientId Yes The client’s identifier
clientSecret Yes The client’s secret

Response:

[{ "kid": "<key_id>", "key": "<public_key>" }]

Each entry contains the key id (kid, matched against the access token header to select the verification key) and the public key itself.

Retrieve the role map

Returns the roles attached to the client as a { [label]: code } map. Use it to resolve the role codes carried in the access token’s roles array.

Property Value
Method POST
Path /api/v1/roles

Body parameters:

Parameter Required Description
clientId Yes The client’s identifier
clientSecret Yes The client’s secret

Response:

{
  "readonly": "readonly_code",
  "admin": "admin_code"
}

The map contains only the roles attached to the requesting client — no filtering is required on your side.

Get the user profile

Applications may want to build their own user profile screens. Vault’s user data can serve as the reference for them.

Property Value
Method GET
Path /api/v1/user

Authentication:

Header Value
Authorization Bearer <access_token>

Response:

{
  "id": "84cf3b03-9b28-4e8c-87a7-1685f1b7ad29",
  "oid": "6abebf76ad2a95dcef049679",
  "firstName": "John Doe",
  "lastName": "Richer",
  "email": "[email protected]",
  "username": "reacher",
  "verified": true,
  "mrn": "mrn:mkit:user:::O6ab4caMwJvG/ZcOVbey2wlqb",
  "slug": "ZcOVbey2wlqb",
  "isLocked": false,
  "roles": [],
  "realm": "3c489d65-450f-4555-a8a4-2b31a4582584"
}

Field notes:

Field Description
oid The user’s ObjectId as a hex string, or null if the user has none
isLocked Whether the user’s realm is locked
roles The user’s roles, as role entities
realm The realm the user belongs to

This call acts as the user: the client application forwards the user’s access token, and Vault identifies the user from the t

Delete the current user

Hard-removes the user identified by the token. Intended to be called by client applications on behalf of a user requesting account deletion.

Property Value
Method DELETE
Path /api/v1/user

Authentication:

Header Value
Authorization Bearer <access_token>

Response: the removed user entity.

Because the request carries the user’s own token, Vault identifies the target from the token itself — no user id is passed in the request, and a client can never purge anyone other than the requesting user.

Making this call hard removes the user entity from Vault. This cannot be undone.

Sync deleted users

Returns the realm’s purge entity collection — tombstones for users deleted within the retention window. Poll this endpoint to mirror user deletions in your own systems.

Property Value
Method POST
Path /api/v1/user/purge

Body parameters:

Parameter Required Description
clientId Yes The client’s identifier
clientSecret Yes The client’s secret

Response:

The realm’s purge entity collection. Each entry contains the former user’s entity id, entityOid (if one existed), and the realm the user belonged to.

Purge entities are retained for 30 days after deletion, after which they are removed permanently. Poll frequently enough to catch all purges before they expire.