A valid request URL is required to generate request examples{
"fulfilments": [
{
"id": "<string>",
"state": "provisioned",
"deviceId": "<string>",
"estimatedBy": "2023-11-07T05:31:56Z",
"sku": "<string>",
"billing": "<string>",
"revocationReason": "subscription_deleted",
"purchasedAt": "2023-11-07T05:31:56Z",
"orderId": "<string>",
"quantity": 2,
"unitIndex": 2,
"initialTermVerified": true,
"deliveryPhase": "preparing",
"model": {
"id": "<string>",
"name": "<string>"
},
"region": "<string>",
"addOns": {
"usFixedIp": true,
"preinstallApps": true
}
}
]
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}{
"error": {
"code": "admission_unavailable",
"message": "<string>"
}
}What your organisation has bought, and where each purchase got to
Your own organisation’s device purchases, newest first. This is the read that lets a paid customer with no device yet be shown something other than an empty screen.
IT IS NOT GET /v1/admission. Admission says which screen a signed-in user sees; this says what was purchased and whether it arrived. They were the same question only while admission was the thing being sold.
WHEN NO DEVICE WAS FREE at the moment a purchase settled, the purchase still succeeds and comes back as awaiting_provisioning with an estimatedBy date. That is a commitment made to the customer, not an error state, and it is the case this endpoint exists for. The date can be moved by us, which is why it is an estimate; every move is recorded.
ANSWERS ONLY ABOUT THE CALLER’S OWN ORGANISATION, taken from the verified credential. An empty list is the organisation asking about itself and discloses nothing about anybody else.
MOUNTED ON EVERY HOSTED DEPLOYMENT, including one that is not finished being set up for provisioning: those answer 503 with Retry-After, not 404, for the reason given on GET /v1/admission.
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{
"fulfilments": [
{
"id": "<string>",
"state": "provisioned",
"deviceId": "<string>",
"estimatedBy": "2023-11-07T05:31:56Z",
"sku": "<string>",
"billing": "<string>",
"revocationReason": "subscription_deleted",
"purchasedAt": "2023-11-07T05:31:56Z",
"orderId": "<string>",
"quantity": 2,
"unitIndex": 2,
"initialTermVerified": true,
"deliveryPhase": "preparing",
"model": {
"id": "<string>",
"name": "<string>"
},
"region": "<string>",
"addOns": {
"usFixedIp": true,
"preinstallApps": true
}
}
]
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}{
"error": {
"code": "admission_unavailable",
"message": "<string>"
}
}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
This organisation's purchases.
This organisation's purchases, newest first.
Show child attributes
Show child attributes