Restore a revision
Republish an older revision as a new revision at the head of this branch. Restore does not overwrite history; the older revision keeps its ID, and a new revision is committed on top.
The response mirrors `POST /agent/{id}/branches/{branchId}/draft/publish`: `200 committed` if the scan is synchronous, `202 scanning` if deferred. Only one publish or restore can be in flight per branch at a time.
Authentication
AuthorizationBearer
API key from the console ApiKey collection, sent as Bearer token. Also accepts session cookies for browser-based auth.
Path parameters
id
The agent ID.
branchId
The branch ID.
revisionId
The revision ID. Equal to the v1 versionId for revisions that were migrated from the v1 model.
Response
Restored synchronously.
status
data
Result of publish or restore.
state: "committed"(HTTP200) is returned when the commit is synchronous. This happens for restore (the source revision has already been scanned) and for publishes whose content does not need a fresh scan. The response includes the new revision object underrevision.state: "scanning"(HTTP202) is returned when a security scan is deferred. In this case the response body carries onlystate.revisionis absent, and clients must list the branch’s revisions newest-first (GET /agent/{id}/branches/{branchId}/revisions?limit=1) to obtain the new revision ID. Then pollGET /agent/{id}/branches/{branchId}/revisions/{revisionId}untilrevision.statusflips from any transient value to"published". On the revision doc the lifecycle field isstatus(notstate), and the security-scan sub-lifecycle is on the nestedsecurityCheck.status.
Errors
400
Bad Request Error
401
Unauthorized Error
403
Forbidden Error
404
Not Found Error
409
Conflict Error
423
Locked Error
500
Internal Server Error

