Undo a change
Replays a bundle's operations backwards, through the same permission compiler as any other write, so undoing a delete re-creates the row only if you could have created it.
POST/v1/changesets/{changesetId}/revert
An update puts back ONLY the fields it changed, so a colleague’s edit to another field of the same record survives. If somebody has changed one of those same fields since, it refuses and says whose: send confirm: true to overwrite theirs anyway. Only a bundle of record creates, edits and deletes can be undone: the changesets list marks each one revertible, and anything else (a comment, a saved view, a page, a change to the app’s shape) is refused up front with the reason rather than half-applied. Every row it can put back is undone in ONE transaction, and a row deleted since is listed in skipped rather than failing the rest.
Requires the records:write scope. Operation changesets.undo. MCP tool changesets_undo. CLI, once published: gtable changesets undo.
Path parameters
| Name | Type | Required | Description |
|---|---|---|---|
changesetId | string | yes |
Headers
| Name | Type | Required | Description |
|---|---|---|---|
Idempotency-Key | string | no | Any unique string. Sending the same key with the same request again returns the first response (marked Idempotency-Replayed: true) instead of running it twice. Reusing it for a different request is refused with 409. Kept for 24 hours. Up to 255 characters. |
Request body
| Field | Type | Required | Description |
|---|---|---|---|
confirm | boolean | no |
Response
Success
dataobjectrequiredRefused
errorobjectrequired