Roll back a site
Re-ships an earlier deployment’s commit to production. Defaults to the previous shipped deployment (the “undo the bad deploy” case); pass deployment_id to target a specific historical deployment instead. Asynchronous: responds 202 with a new pending deployment whose status moves to live/failed. Poll GET /sites/{id}/deployments to track it.
Authorizations
API key in the format: Bearer {api_token}
Headers
Makes this write safe to retry: a repeat with the same key replays the first response instead of creating a second resource. Scoped to the account, remembered for 24 hours; reusing a key with a different payload is an error.
255Path Parameters
The resource ID (e.g., "prod_abc123") or slug (e.g., "my-product")
Body
Id of a specific deployment to roll back to (e.g. "dpl_abc123"), from the deploy history. Omit to roll back to the previous shipped deployment.
Also rewind the site's database to the schema that deployment was serving, using the restore point captured before the deploy that followed it. Off by default: rolling code back is cheap, but a database restore discards every row written since the target shipped. Returns no_restore_point when no restore point was recorded after the target.
Response
The queued rollback deployment
pending, building, live, failed, superseded, unpublished 
