A valid request URL is required to generate request examples{
"changes": [
{
"previousEstimatedBy": "2023-11-07T05:31:56Z",
"estimatedBy": "2023-11-07T05:31:56Z",
"changedBy": "<string>",
"note": "<string>",
"changedAt": "2023-11-07T05:31:56Z"
}
]
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "not_found",
"message": "<string>"
}
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}Every time the date on an order moved, and why
When a purchase settles against an empty shelf it comes back as awaiting_provisioning with a date, and that date is an ESTIMATE rather than a promise precisely because we may move it. This is the record of every time we did, newest first, with who did it and why.
IT IS PUBLISHED FOR THE REASON THE DATE IS MOVABLE. A date that quietly slides is worse than a late one: the customer cannot tell whether anybody is working on it. An order whose date has never moved answers an empty list, which is the ordinary case.
A SEPARATE READ from the order list on purpose. The history is unbounded and only the order somebody has opened needs it; folding it into the listing would make every Orders page carry every move of every date so that one expanded panel could be drawn without a second request.
AN ORDER YOUR ORGANISATION DOES NOT HAVE answers exactly as one that never existed does. Answering differently would make this a way to find out whether somebody else’s order id is real.
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{
"changes": [
{
"previousEstimatedBy": "2023-11-07T05:31:56Z",
"estimatedBy": "2023-11-07T05:31:56Z",
"changedBy": "<string>",
"note": "<string>",
"changedAt": "2023-11-07T05:31:56Z"
}
]
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "not_found",
"message": "<string>"
}
}{
"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.
Path Parameters
The order id, as GET /v1/fulfilments reports it.
Response
This order's estimate changes, newest first.
One order's estimate changes, newest first. Empty when the date has never moved.
Show child attributes
Show child attributes