Stack Overflow Revision History and Stack Exchange API: Identifying Rollback Events

Direct answer

The Stack Exchange API does not provide a documented, machine-readable flag whose sole purpose is to mark a revision as rollback-initiated. Revision comments are editable and unreliable. The practical approach is to use revision_type (or the equivalent post-history type) when your filter returns it, and otherwise infer a rollback by comparing normalized content across revisions.

Confirmed facts vs. likely behavior

Confirmed: a rollback is stored as a new revision with a later creation date; it does not mutate the original revision in place.

Confirmed: no hidden or undocumented boolean is documented for rollback intent.

Expected but version-dependent: some endpoints and filters expose revision_type or a post-history type. Exact field names and enumerated values vary by API version and filter, so verify against the current schema before coding.

Steps to identify a probable rollback

1. Fetch the post's revisions with a filter that includes body, title, tags, and revision metadata. For example, using the public API:

curl -s "https://api.stackexchange.com/2.3/posts/{POST_ID}/revisions?site=stackoverflow&filter=withbody" | jq '.items[] | {revision_number, creation_date, revision_type, body, title, tags}'

Replace {POST_ID} and confirm the filter name against the current API documentation.

1. If revision_type is present, treat values that indicate rollback as rollback events. Because the enumeration differs across versions, map the observed value to your own enum rather than hard-coding a string.
2. If no rollback indicator is returned, normalize each revision's body, title, and tags by trimming whitespace and canonicalizing markup.
3. Compare the candidate revision against all older revisions for the same post. An exact match to an earlier state, combined with a later creation date or revision number, indicates a restoration.
4. Classify the result as a probable rollback, not a confirmed moderator action. A manual edit that recreates old content produces the same API signature.

Assumptions and uncertainty

• Field names and revision_type values are not guaranteed across API versions or filters; verify with a live call before relying on them.
• Content equality is a heuristic. It cannot distinguish moderator intent from a user manually reverting text.
• Deleted, locked, merged, or migrated posts may expose different or restricted revision histories.
• Use only the public API and respect rate limits; do not scrape undocumented UI attributes.

If your current filter already returns revision_type, the first two steps are sufficient. If it does not, the content-comparison fallback is the only API-only method available.