A valid request URL is required to generate request examples{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "not_found",
"message": "<string>"
}
}{
"error": {
"code": "rate_limited",
"message": "<string>"
}
}Pick a cut copilot stream back up
A phone that went to the background, a tab switched away from, a network that dropped. Reconnect here, say which message you were reading and how many of its parts you already have, and the rest arrives as the same UI message chunks the live stream sends, under the same header and ending with the same data: [DONE].
since is the messageId from the start chunk you were reading. afterPart is how many parts of it you already hold, so 0 (the default) replays the whole message and a number past its end sends the frame and nothing inside it, which is how you learn you are caught up. Omit since and the newest assistant message is replayed from the beginning, which is what a client that lost its place entirely needs. A since naming no message of this thread replays NOTHING rather than restarting from the top: restarting would repeat what you already have and hide that your cursor is stale.
NO MODEL IS ASKED ANYTHING AND NOTHING IS WRITTEN. This reads a stored message back, so it answers the same on a deployment with no copilot configured, costs no tokens, and cannot change the thread.
WHAT IT DOES NOT DO. It does not rejoin a turn that is still running, because after a disconnect there is not one: closing the request aborts the turn, the copilot stops before its next step or tool call, and what it had is written. So a reconnect delivers everything you missed up to the moment the connection died, and the turn does not carry on in the background.
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{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "unauthorized",
"reason": "missing_credentials",
"hint": "<string>"
}
}{
"error": {
"code": "backend_resolution_failed",
"message": "<string>",
"retryable": true
}
}{
"error": {
"code": "not_found",
"message": "<string>"
}
}{
"error": {
"code": "rate_limited",
"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.
Path Parameters
The thread id.
Query Parameters
The messageId you were reading. Omit it for the newest assistant message.
^[A-Za-z0-9_-]{1,128}$How many parts of that message you already hold. Zero or more; zero replays the whole message.
x >= 0Response
The chunks you had not seen, ended by data: [DONE]. Empty of parts when there is nothing owed.