Skip to main content
POST
Update dashboard

Restrictions

Usage

  • The definition is replaced whole; there is no partial update.
  • expected_revision must equal the current revision, otherwise the call fails with HTTP 409 DashboardRevisionConflict. Re-read with POST /rum/dashboard/get and retry.
  • An unchanged definition returns changed: false and keeps the current revision.
  • Each change stores a revision (up to 20 are kept) with the optional message.
  • A dashboard that does not exist returns HTTP 404 DashboardNotFound; one in the trash returns HTTP 410 DashboardDeleted.
  • A body over 2 MiB, a definition over 1 MiB, or exceeding a count limit returns HTTP 413 EntityTooLarge; a schema_version other than dashboard.v1 returns HTTP 422 UnsupportedSchemaVersion.
  • Applications are verified as on create.

Authorizations

app_key
string
query
required

APP Key created in the Flashduty console under My → APP Key. Send it as the app_key query parameter or in the Fd-App-Key request header. Its effective access is the intersection of the key's permission scope and the creator's current role permissions. Keep it secret.

Body

application/json

Update request. expected_revision makes the write conditional: the update fails with DashboardRevisionConflict when the dashboard has moved on.

dashboard_id
string
required

Dashboard ID, a canonical UUIDv7.

Pattern: ^[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$
schema_version
enum<string>
required

Wire schema of the definition. Must be dashboard.v1.

Available options:
dashboard.v1
expected_revision
integer
required

Revision the caller last read. Must be at least 1.

Required range: x >= 1
definition
object
required

The dashboard body: title, default time range, variables, and tabs. A dashboard is capped at 10 tabs, 100 panels and 300 queries. A tab holds at most 30 panels and 100 queries, top panels and sections together.

message
string

Optional change message stored with the revision, at most 1024 characters.

Maximum string length: 1024

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

Result of an update. changed is false when the submitted definition matched the stored one, in which case resource is still returned.