Task-shaped pages: a title that starts with a verb, the situation in a few lines, the steps, the working code in both engines, and why this way rather than another. Found from a search, done, and left.
Every save keeps the revision before it. Find the one that was right and send its id as activeRevision on the page: it is live again at once, with no new revision. Then base the next edit on it with originRevision, or the edit brings back what you rolled back.
Context. An import wrote the wrong text into a hundred pages, or an editor published a change that has to come off now. Nothing is lost: each save made a new revision and kept the old one. Rolling back is making an older revision the live one again, which is a single request per page.
Credentials for a backend user who may edit pages, and the page id. To find the revision to go back to, the admin's revision history is the easiest view; the API gives the same list.
GET /cdna-api/pages/page/1885?properties={id,activeRevision{id},revisions{id,created,name}}. They come oldest first. To see what one holds, the admin's history compares them; through the API, revisions{id,areasContent} returns every revision's content, which is a large answer on an old page.activeRevision, at the top level of the body: {"activeRevision": 3482}."originRevision": 3482 inside patchRevision. The newer revision you rolled away from is still the newest one, and a patch without an origin copies it.PUT /cdna-api/pages/page/1885?properties={id,activeRevision{id,navSection:areaText(navSection)}}
Content-Type: application/json
{"activeRevision": 3482}{
"result": "success",
"data": {
"id": 1885,
"activeRevision": {
"id": 3482,
"navSection": "API sandbox"
}
},
"message": "The Page has been saved successfully."
}The real answer on this site's sandbox page, rolling back the change made in Change one area: revision 3483 had set navSection to devdocs, and 3482 is live again with the old value. No revision was created by the rollback.
Other record types roll back in their own ways:
| Record | Request |
|---|---|
| Pages, books and their units and pages, blog posts, FAQ pages and questions | {"activeRevision": <id>} on the record's edit route |
| Custom entity records | The same, or PUT /cdna-api/custom-entities/activate-revision/{record}/{revision} |
| Forms | PUT /cdna-api/forms/activate-form-revision with revision_id |
Not a new edit that types the old content back: it makes a third revision holding only what you remember to copy across, and takes longer. Not deleting the bad revision: no API route deletes a page's revision, and the rollback does not need it gone. Not a rollback through patchRevision: inside a patch, activeRevision is true or false, about the new revision; the id goes at the top level. And the rollback changes content only: published is separate, so a page that was unpublished stays unpublished.
Was this page helpful?
Your answer goes to the docs team.