Skip to main content
POST
Revert preset severity rules to a history snapshot

Restrictions

Usage

  • Replaces the entire current rule set with the snapshot’s rows: rule_id, priority, filters, severity, status, and created_by are preserved from the snapshot, but created_at/updated_at are reset to the revert time and updated_by is set to the reverting user.
  • Returns InvalidParameter (not ResourceNotFound) when version does not correspond to an existing history snapshot for the application.
  • The revert itself is captured as a new history snapshot before it is applied, so a revert can itself be reverted.
  • Every call is recorded in the account audit log. Don’t put secrets in request fields.

Authorizations

app_key
string
query
required

App key issued from the Flashduty console under Account → APP Keys. Required on every public API call. Keep it secret — it grants the same access as the owning account.

Body

application/json

Parameters for reverting to a history snapshot.

application_id
string
required

RUM application ID. Get application IDs via POST /rum/application/list.

version
integer
required

Snapshot version number to revert to. Get versions via POST /rum/issue/preset-severity/rules/history/list.

Required range: x >= 1

Response

Success

Success response envelope. On every 2xx response, request_id identifies the call (also mirrored in the Flashcat-Request-Id header) and data holds the endpoint-specific payload. Failure responses use a different shape — see ErrorResponse.

request_id
string
required

Unique ID for this request. Mirrored in the Flashcat-Request-Id response header. Include it when reporting issues.

Example:

"01HK8XQE3Z7JM2NTFQ5YJ8P9R4"

data
object
required

Empty response body. The server returns data: null on success.