Skip to main content
POST
Reorder preset severity rule

Restrictions

Usage

  • This moves exactly one rule, not a full reordering: drag_rule_id’s priority is set to target_rule_id’s current priority, and every rule between the two original positions — the target rule itself included — shifts by one to close the gap.
  • Lower priority numbers are evaluated first; moving toward a lower-numbered target moves the rule earlier in evaluation order, and toward a higher-numbered target moves it later.
  • Returns ResourceNotFound if either drag_rule_id or target_rule_id does not exist in the application.
  • 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 moving one rule to another rule's evaluation position.

application_id
string
required

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

drag_rule_id
string
required

ID of the rule being moved. Get rule IDs via POST /rum/issue/preset-severity/rules/list.

target_rule_id
string
required

ID of the rule whose evaluation position drag_rule_id moves to.

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.