Skip to main content
POST
Bind work items to a post-mortem

Restrictions

Usage

  • Requires the On-call Pro license.
  • Binds ALL of the incident’s converted-but-unbound follow-ups to the given post-mortem in one call.
  • items holds the newly bound batch; next_cursor and has_more are not set.
  • Idempotent by idempotency_key — retrying with the same key replays the original result.
  • Audited — changes are recorded in the audit log.

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 bulk-binding an incident's unbound follow-ups to a post-mortem.

post_mortem_id
string
required

Post-mortem ID (32-character hex string) to bind the follow-ups to.

incident_id
string
required

Incident ID (MongoDB ObjectID) whose converted-but-unbound follow-ups are bound.

Pattern: ^[0-9a-fA-F]{24}$
idempotency_key
string
required

Client-generated idempotency key (max 128 characters; letters, digits, _, -, ., : only).

Maximum string length: 128
Pattern: ^[A-Za-z0-9_\-.:]+$

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

Cursor-paginated list of work items.