Create a work item
Create an action on an active incident or a follow-up on one of its post-mortems.
Restrictions
Usage
- Requires the On-call Pro license.
- An
actionanchors to an active incident and must NOT setpost_mortem_id; afollow_upREQUIRES thepost_mortem_idof a post-mortem linked toincident_id. - Assignees must be active members who can already read the anchor incident or post-mortem — assignment never grants access.
- Newly added assignees are notified.
- Retrying with the same (
creator,idempotency_key) replays the original item withidempotent_replay: trueinstead of creating a duplicate. - Audited — changes are recorded in the audit log.
Authorizations
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
Parameters for creating an incident work item.
action anchors to an active incident and must not set post_mortem_id; follow_up requires post_mortem_id.
action, follow_up Item title (max 512 characters).
512Incident ID (MongoDB ObjectID) the item is anchored to.
^[0-9a-fA-F]{24}$Client-generated idempotency key (max 128 characters; letters, digits, _, -, ., : only).
128^[A-Za-z0-9_\-.:]+$Optional longer description (max 65,535 characters).
65535Optional client-defined initial status (max 64 characters).
64Optional client-defined priority (max 64 characters).
64Post-mortem ID (32-character hex string). Required for follow_up, forbidden for action. The post-mortem must be linked to incident_id.
Initial assignee member IDs. Assignees must be active members who can already read the anchor; assignment never grants access.
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.