Restore a site's database to a point in time
Rewinds the site’s database to a restore point or an ISO 8601 timestamp — the undo for data you didn’t mean to lose. One of the two is required. Restore points come from db/migrations, where every applied change carries the restore_to it began from; nothing has to capture one in advance.
The restore overwrites current state, but earlier points are retained, so an overshoot can itself be undone via previous_bookmark. Points are kept for 30 days.
This is not how a schema change is removed. A restore rewinds this database’s shape too, but the development database still has the newer one — so the next deploy compares them and puts it back. To drop a table for good, remove it from the development database and deploy.
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
A restore point, as returned by db/migrations (restore_to) or by a migration's own response.
An ISO 8601 timestamp to rewind to (nearest point at or before).
Which database to use. A site normally has exactly one, production, and that is the default — the live database the site reads. development is only valid if a separate development database has been provisioned for this site; asking for one that doesn't exist is an error rather than a silent fall back to production. The response echoes the environment that was used.
development, production 
