Skip to main content
Source history is append-only, so every recovery creates a new version — you can always undo an undo.

​
Prerequisites

​
The two recovery tools

Both run under the website’s edit lease. Cactal takes it for you when you omit leaseToken, but refuses with 409 Another editor is changing this website if another editor is still working on the website, such as the Cactal agent while it runs or someone who changed it in the last 5 minutes. In a recovery you usually want to take over, so acquire the lease first and pass its token, as below.
1

Acquire the edit lease

Acquire a lease
The response { "leaseToken": "...", "headVersion": 9 } also tells you the current head version. GET /v1/websiteSourceCode/summary reports headVersion, publishedVersion, and hasUnpublishedChanges if you need orientation first.
2

Discard the draft

Restore the head to match the published website. Production does not change.
Restore head to published
The response is { "version": 10, "changed": true }, a new head version containing the published files. If head already matched, changed is false. A website that has never published returns 404.
3

Restore an older version to head

Bring back a known-good version for review by passing a version number as to. This changes only the draft:
Restore version 7 to head
to must be an existing version (1 up to the current head); anything higher returns 400 Version does not exist. Review the result on the draft host, then take it live with the normal pipeline: POST /v1/websiteSourceCode/head/check, then POST /v1/websiteSourceCode/head/publish.
4

Roll back the published website immediately

When production is broken, skip the review loop. Rollback validates version n, builds it, and re-publishes in one call:
Roll back production to version 7
Response
Rollback re-runs the full publish gate: the version must pass validation and build. It does not require billing. It also moves head to the rolled-back content, so head and published end up aligned.
5

Recover from a failed build

A publish that fails validation or build returns a 400 with the failure message, and the deployment records status: "failed". Inspect it:
Check deployment status
Response (truncated)
The recovery loop: fix the offending source file, run POST /v1/websiteSourceCode/head/check until it passes, then publish again. POST /v1/websiteSourceCode/deployment/ensure (body { websiteId, target }) re-triggers a build for the head or published version without publishing — useful to confirm a fix builds cleanly. The published website keeps serving its last ready deployment throughout; a failed build never takes production down.
6

Verify the outcome

List files changed from published to head to confirm the state you expect:
List changed files
After a rollback or a restore to published you should see "items": [], meaning head and published match. After restoring an older version to head, items lists what will change when you publish. Inspect a selected entry with GET /v1/websiteSourceCode/files/diff?websiteId=...&name=....

​
Troubleshooting

Another editor acquired the lease after you did. Re-acquire the lease and repeat the operation.
You sent no leaseToken while another editor was active. Acquire the lease to take over, then repeat the operation with its token.
Rollback found a build in progress for that version. Retry after a short wait; the build is reused once ready.
Restoring to published and comparing against published need at least one publish. Restore to a version number instead on a never-published website.

​
Next steps