Skip to main content
POST
Create an error ingestion rule

Restrictions

Usage

  • Create, update, enable, disable, and delete all snapshot the application’s full current rule set into history first, so history/list reflects every mutation.
  • Every condition key in filters must be one of the supported error.* fields or a context.* path; unsupported keys are rejected with InvalidParameter.
  • New rules are created with status enabled; call disable afterward if the rule should start inactive.
  • 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

Fields for creating a new error ingestion rule.

application_id
string
required

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

rule_name
string
required

Rule name, 1-128 characters.

Required string length: 1 - 128
filters
object[][]
required

Filter conditions (OR-of-ANDs) to match errors; matched errors are dropped and not ingested.

AND-group. The group only matches when every condition inside it matches.

description
string

Rule description, up to 512 characters.

Maximum string length: 512

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

The newly created rule's identity.