Restore a past revision into the draft
Loads a past snapshot back into the DRAFT. It does not make it live. The response is a configuration whose draft changed and whose published did not, so review it and publish when you are ready. A one-call rollback straight to live would change what every shopper sees with nobody having looked at it. It OVERWRITES the draft, which is why it carries the same expected_updated_at a draft save does: without one it would discard another integration’s unsaved work while naming no document at all.
Authorizations
A secret API key. Publishable keys cannot reach this API. A key may carry an expiry, and an expired key is refused exactly like an unknown one, with a 401 that names no reason; check the key's expires_at in the dashboard rather than inferring it from a response. When a merchant rolls a key's secret they choose a grace window of up to 3 days, and for its duration BOTH the new secret and the one it replaced authenticate, so an integration moves over on its own deploy schedule instead of at the instant the button is pressed. Move before the window closes: after it, the old secret is refused. Nothing else about this contract moves with a roll. The key keeps its id and its scopes, so the only thing an integration updates is the credential itself.
Headers
A unique key per logical write. Replaying a request with the same key returns the first response byte for byte instead of applying the write twice.
Path Parameters
Body
The revision is named in the PATH, so revision_id in the body is refused; so is config, because a restore copies the stored snapshot and is not a way to write a document of your own.
The updated_at you last read. Required and not nullable: a restore OVERWRITES the draft, so without it this call would discard another integration's unsaved work while naming no document at all.
Response
Success
