A valid request URL is required to generate request examples{
"leases": [
{
"deviceId": "<string>",
"acquiredAt": "<string>",
"expiresAt": "<string>",
"holder": {
"kind": "api_key",
"viaCopilot": true,
"userId": "<string>",
"apiKeyId": "<string>",
"onBehalfOf": {
"kind": "schedule",
"scheduleId": "<string>",
"userId": "<string>",
"apiKeyId": "<string>"
}
}
}
]
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}List the devices your organisation currently holds
The leases your organisation holds right now, among the devices this credential can see. This is what answers “how many of my devices are in use”; GET /v1/devices answers how many exist and how many are reachable, and the two are different questions.
A DEVICE MISSING FROM THIS LIST IS NOT AVAILABLE TO YOU. It means only that you hold no live lease on it. It may be held by someone else, or your quota may be spent: the acquire call is deliberately unable to tell those apart, and this endpoint does not tell you either. Acquiring is the only thing that answers whether you can acquire.
The listing can never name a device GET /v1/devices would not: leases are looked up for the devices that listing returns, so a key narrowed to a subset of devices sees leases only within that subset.
The lease id and fencing token are not returned. The id is the credential release_device checks, and publishing it to every reader would let one of your runs release another’s lease.
Ordered by expiry, soonest first.
Hosted deployments only. A local checkout does not mount this route, so calling it there is a 404.
A valid request URL is required to generate request examples{
"leases": [
{
"deviceId": "<string>",
"acquiredAt": "<string>",
"expiresAt": "<string>",
"holder": {
"kind": "api_key",
"viaCopilot": true,
"userId": "<string>",
"apiKeyId": "<string>",
"onBehalfOf": {
"kind": "schedule",
"scheduleId": "<string>",
"userId": "<string>",
"apiKeyId": "<string>"
}
}
}
]
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}Authorizations
The control surface credential. Send Authorization: Bearer <token>.
Two kinds of token are accepted and they are told apart by shape, not by a separate header. A token beginning pbk_ is an org scoped API key, whose public half and secret half are generated together and of which only a hash of the secret is ever stored; anything else is treated as an OAuth 2.1 access token and verified against the authorization server's keys.
Both resolve to the same context: an org, a principal and a set of scopes. Nothing downstream branches on which channel you used, with one deliberate exception, key management, which requires a signed-in person so that a key can never mint another key.
Scopes are enforced when MCP tools are REGISTERED rather than when they are called, so a tool your credential cannot use is absent from tools/list rather than refused mid gesture.
Response
Your organisation's live leases.
Every device you can see that your organisation currently holds a live lease on.
Show child attributes
Show child attributes