Incident Webhook

Configure incident Webhook. When specific operations occur on incidents (such as trigger or close), the system makes an HTTP callback to your configured address. The callback content includes the incident’s latest key information, allowing integration with your custom tools.

Event types

Flashduty currently supports the following event types and may add more later.

Event Type	Description
i_new	Create incident (auto or manual)
i_assign	Assign incident (auto or manual)
i_a_rspd	Add responders (currently only subscribable with the API)
i_snooze	Manually snooze incident
i_wake	Cancel snooze
i_ack	Manually acknowledge incident
i_unack	Cancel acknowledgment
i_storm	Trigger storm warning
i_custom	Trigger custom action
i_rslv	Close incident (auto or manual)
i_reopen	Reopen incident
i_merge	Manually merge incident
i_comm	Add comment
i_r_title	Update incident title
i_r_desc	Update incident description
i_r_impact	Update incident impact
i_r_rc	Update incident root cause
i_r_rsltn	Update incident resolution
i_r_severity	Update incident severity
i_r_field	Update incident custom field
i_wi_created	Create action or follow-up (currently only subscribable with the API)
i_wi_assignees	Update action or follow-up assignees (currently only subscribable with the API)
i_wi_completed	Complete action or follow-up (currently only subscribable with the API)
i_wi_converted	Convert action to follow-up (currently only subscribable with the API)

Push description

Request method

POST, Content-Type:“application/json”

Request payload:

Field	Type	Required	Description
event_time	int64	Yes	Event timestamp in `milliseconds`
event_type	string	Yes	Event type, enum values see Event Types
event_id	string	Yes	Event ID, `the same event may retry multiple times due to timeout, receiver needs to deduplicate`
event_detail	object	No	Event details, the structure varies with event_type, see Event details; for event types not listed, it is always an empty object `{}`
person	Person	No	Operator, only exists for human actions
incident	Incident	Yes	Incident details

Person:

Field	Type	Required	Description
person_id	int64	Yes	Person ID
person_name	string	Yes	Person name
email	string	Yes	Email address

Responder:

Field	Type	Required	Description
person_id	int64	Yes	Person ID
person_name	string	Yes	Person name
email	string	Yes	Email address
assigned_at	int64	No	Assignment time
acknowledged_at	int64	No	Acknowledgment time

AssignedTo:

Field	Type	Required	Description
person_ids	[]int64	No	List of directly assigned person IDs; present when assigned directly to specific people
escalate_rule_id	string	No	Escalation rule ID; present when assigned by an escalation rule
escalate_rule_name	string	No	Escalation rule name
layer_idx	int	Yes	Current escalation layer, starting from 0
type	string	Yes	Assignment method, enum values: assign (assignment), reassign (reassignment), escalate (layer escalation), reopen (assignment after reopen)
id	string	Yes	Assignment record ID
assigned_at	int64	Yes	Assignment time, Unix seconds timestamp
effective_person_ids	[]int64	No	Person IDs in effect for this assignment. It’s the union of directly assigned people and people resolved by the escalation rule, deduplicated and sorted by ID

LinkItem:

Field	Type	Required	Description
name	string	Yes	Link name
endpoint	string	Yes	Target URL; template variables configured in the link integration have been replaced with the current incident’s actual values
open_type	string	Yes	Open method, enum values: popup, tab (new tab)

IncidentShort:

Field	Type	Required	Description
incident_id	string	Yes	Incident ID
title	string	No	Incident title

Image:

Field	Type	Required	Description
src	string	Yes	Image URL
href	string	Yes	Click-through URL; may be an empty string
alt	string	Yes	Caption; may be an empty string

Incident:

Field	Type	Required	Description
incident_id	string	Yes	Incident ID
account_id	int64	Yes	Account ID
account_name	string	Yes	Account name
title	string	Yes	Incident title
description	string	No	Incident description
impact	string	No	Incident impact
root_cause	string	No	Incident root cause
resolution	string	No	Incident resolution
incident_severity	string	Yes	Severity, enum: Critical, Warning, Info
incident_status	string	Yes	Incident status, enum: Critical, Warning, Info, Ok
progress	string	Yes	Progress, enum: Triggered, Processing, Closed
created_at	int64	Yes	Created time
updated_at	int64	Yes	Updated time
start_time	int64	Yes	Trigger time, Unix seconds timestamp
last_time	int64	No	Latest event time, latest event push time in associated alerts, Unix seconds timestamp, default 0
end_time	int64	No	Recovery time, incident auto-recovers when all associated alerts recover, Unix seconds timestamp, default 0
ack_time	int64	No	First acknowledgment time, incident can be acknowledged by multiple people, this is the earliest acknowledgment time. Unix seconds timestamp, default 0
close_time	int64	No	Close time, end_time represents incident recovery time, close_time represents progress close time, incident closes when recovered, closing doesn’t affect recovery. Unix seconds timestamp, default 0
snoozed_before	int64	No	Snooze deadline
labels	map[string]string	No	Label KV, both Key and Value are strings. Not present for manual creation, for auto creation it’s the labels of the first grouped alert
fields	map[string]interface	No	Custom field KV, Key is string, Value can be any type depending on field type
creator	Person	No	Creator info, only exists for manually created incidents
closer	Person	No	Closer info, only exists for manually closed incidents
creator_id	int64	Yes	Creator ID, non-zero only for manually created incidents
closer_id	int64	Yes	Closer ID, non-zero only for manually closed incidents
owner_id	int64	Yes	Owner ID, reserved field
responders	[]Responder	No	Responders list, only exists after incident is assigned. May be empty for i_new events
dedup_key	string	Yes	Deduplication key, grouping identifier; valid for auto-created incidents, empty string for manually created incidents
assigned_to	AssignedTo	No	Assignment info, only exists after incident is assigned
alert_cnt	int64	No	Associated alert count
active_alert_cnt	int64	No	Reserved field, always 0 in current pushes, use alert_cnt instead
integration_id	int64	Yes	Integration ID of the first associated alert; 0 when there is no associated alert
integration_ids	[]int64	No	Integration IDs of the associated alerts
integration_types	[]string	No	Integration types of the associated alerts
data_source_id	int64	Yes	Legacy field (Deprecated), same as integration_id, use integration_id instead
data_source_ids	[]int64	No	Legacy field (Deprecated), same as integration_ids
num	string	Yes	Short incident identifier — the last 6 hex characters of the incident ObjectID, uppercased (for example, `56E25B`). Displayed in the console UI. Can be passed to the incident info API as an alternative to `incident_id` (either field is accepted; not unique within an account — the most recently created match is returned)
channel_id	int64	No	Channel ID, 0 means not belonging to any channel
channel_name	string	No	Channel name
channel_status	string	Yes	Channel status, enum: enabled, disabled; empty string when the incident belongs to no channel
team_id	int64	No	ID of the team that owns the channel; 0 when the channel has no owning team
detail_url	string	Yes	Detail URL
silence_url	string	Yes	Quick silence page URL
links	[]LinkItem	No	Link integrations associated with the channel; this field is not returned when none are configured
group_method	string	No	Grouping method, enum: n: no grouping, p: rule-based grouping, i: intelligent grouping
has_unfinished_work_item	bool	Yes	Whether the incident still has unfinished action items or follow-ups
post_mortem_id	string	Yes	Associated post-mortem ID, deterministically generated from the associated incident set; `"0"` when there is none
images	[]Image	Yes	Incident image list; null when there are no images

Event details (event_detail)

The structure of event_detail varies with event_type; the field definitions for each event type are listed below. For event types not listed (i_r_impact, i_r_rc, i_r_rsltn), event_detail is always an empty object {}. i_new:

Field	Type	Required	Description
severity	string	No	Incident severity, same values as incident.incident_severity
title	string	No	Incident title
reporter_email	string	No	Reporter email; present when the incident is created through a reporting channel such as email

i_assign (all AssignedTo fields, plus):

Field	Type	Required	Description
to	[]int64	No	IDs of people newly added by this assignment

i_a_rspd:

Field	Type	Required	Description
to	[]int64	No	IDs of the responders added this time

i_snooze:

Field	Type	Required	Description
minutes	int64	No	Snooze duration in minutes

i_wake:

Field	Type	Required	Description
snoozedBefore	int64	No	Snooze deadline before waking, Unix seconds timestamp. Note the field name is camelCase `snoozedBefore`

i_ack:

Field	Type	Required	Description
progress	string	No	Progress at acknowledgment
comment	string	No	Acknowledgment note (markdown); present only when the acknowledgment form is enabled
images	[]Image	No	Acknowledgment form image list

i_unack:

Field	Type	Required	Description
progress	string	No	Progress at unacknowledgment

i_storm:

Field	Type	Required	Description
threshold	int	No	Storm alert threshold, the maximum number of incidents within the time window

i_custom:

Field	Type	Required	Description
integration_id	int64	No	ID of the triggered custom action integration
integration_name	string	No	Name of the triggered custom action integration

i_rslv:

Field	Type	Required	Description
from	string	Yes	Close source, enum values: voice, console, card (IM card), wcard (WeCom card), event, autorslv (auto recovery), autorefresh, escalation (escalation)
comment	string	No	Close note (markdown); present only when the close form is enabled
images	[]Image	No	Close form image list

i_reopen:

Field	Type	Required	Description
reason	string	No	Reopen reason

i_merge:

Field	Type	Required	Description
comment	string	No	Merge note
source_incidents	[]IncidentShort	No	List of the merged (source) incidents
target_incident	IncidentShort	No	Target incident after the merge

i_comm:

Field	Type	Required	Description
comment	string	No	Comment content, rich-text quotes are rendered as plain text
mute_reply	bool	No	Whether the reply is muted
comment_type_id	string	No	Comment type ID
comment_type	object	No	Comment type display info

i_r_title, i_r_desc:

Field	Type	Required	Description
from	string	Yes	Value before the change
to	string	Yes	Value after the change

i_r_severity:

Field	Type	Required	Description
from	string	Yes	Severity before the change, enum values: Critical, Warning, Info
to	string	Yes	Severity after the change, enum values: Critical, Warning, Info

i_r_field:

Field	Type	Required	Description
field_name	string	Yes	Custom field name
to	object	No	Field value after the change; the type depends on the field’s type definition

i_wi_created:

Field	Type	Required	Description
work_item_id	string	Yes	Action item or follow-up ID
item_type	string	Yes	Type, enum values: action, follow_up
title	string	Yes	Title
status	string	No	Status
assignee_ids	[]int64	No	Assignee ID list
post_mortem_id	string	No	Associated post-mortem ID

i_wi_assignees:

Field	Type	Required	Description
work_item_id	string	Yes	Action item or follow-up ID
item_type	string	Yes	Type, enum values: action, follow_up
title	string	Yes	Title
assignee_ids	[]int64	No	Assignee ID list after the change
added_assignee_ids	[]int64	No	IDs of the added assignees
removed_assignee_ids	[]int64	No	IDs of the removed assignees

i_wi_completed:

Field	Type	Required	Description
work_item_id	string	Yes	Action item or follow-up ID
item_type	string	Yes	Type, enum values: action, follow_up
title	string	Yes	Title
from_status	string	No	Status before completion
to_status	string	Yes	Status after completion
post_mortem_id	string	No	Associated post-mortem ID

i_wi_converted:

Field	Type	Required	Description
work_item_id	string	Yes	Action item or follow-up ID
title	string	Yes	Title
from_type	string	Yes	Type before conversion, enum values: action, follow_up
to_type	string	Yes	Type after conversion, enum values: action, follow_up
status	string	No	Status after conversion
post_mortem_id	string	No	Associated post-mortem ID

Request response

HTTP status code 200 indicates successful push.

Request example

curl -X POST 'https://example.com/incident/webhook?a=a' \
-H 'Content-Type: application/json' \
-H 'X-Customize-Header-A: a' \
-d '{
    "event_detail":{
        "severity":"Critical",
        "title":"ysy028"
    },
    "event_id":"fac0599a2a25529ba2362c0c184b6cfb",
    "event_time":1689335086948,
    "event_type":"i_new",
    "incident":{
        "account_id":74058170041504,
        "account_name":"TouTie Tech kk",
        "ack_time":0,
        "alert_cnt":0,
        "assigned_to":{
            "assigned_at":1689335086,
            "escalate_rule_id":"64abb8a687e7984845822139",
            "escalate_rule_name":"Default Escalation",
            "id":"NBRbNwDSTSMijKXdLtBU3T",
            "layer_idx":0,
            "type":"assign"
        },
        "channel_id":1840312623504,
        "channel_name":"Reduce Noise",
        "channel_status":"enabled",
        "close_time":0,
        "created_at":1689335086,
        "creator":{
            "email":"toutie@flashcat.cloud",
            "person_id":1552048792504,
            "person_name":"TouTie"
        },
        "creator_id":1552048792504,
        "data_source_id":0,
        "dedup_key":"",
        "description":"",
        "detail_url":"http://10.206.0.17:8567/incident/detail/64b1352e376e32c85c56e25b",
        "end_time":0,
        "equals_md5":"",
        "group_method":"n",
        "has_unfinished_work_item":false,
        "images":null,
        "impact":"",
        "incident_id":"64b1352e376e32c85c56e25b",
        "incident_severity":"Critical",
        "incident_status":"Critical",
        "integration_id":0,
        "labels":{
            "check":"cpu idle low"
        },
        "last_time":1689335086,
        "num":"56E25B",
        "post_mortem_id":"0",
        "progress":"Triggered",
        "resolution":"",
        "responders":[
            {
                "acknowledged_at":0,
                "assigned_at":1689335086,
                "email":"toutie@flashcat.cloud",
                "person_id":1552048792504,
                "person_name":"TouTie"
            }
        ],
        "root_cause":"",
        "silence_url":"http://10.206.0.17:8567/channel/detail/1840312623504?tab=alertSuppression&fromIncidentId=64b1352e376e32c85c56e25b",
        "snoozed_before":0,
        "start_time":1689335086,
        "title":"ysy028",
        "updated_at":1689335086
    },
    "person":{
        "email":"toutie@flashcat.cloud",
        "person_id":1552048792504,
        "person_name":"TouTie"
    }
}' -v

Configuration guide

Go to Integration Center → Webhook → Add or edit an Incident Webhook integration.

Basic settings

Enter the integration name and description for easy management.

Webhook settings

Config Item	Description
Managing Team	Select the team that manages this integration; only team members can edit the integration configuration
Endpoint	HTTP/HTTPS address to receive callbacks, must start with `http://` or `https://`
TLS Verification	Enabled by default. When disabled, TLS certificate verification of the target server is skipped; suitable for test environments or self-signed certificates
Headers	Custom request headers in Key-Value format; multiple headers supported
Channels	Select All Channels or Specific Channels. When specific channels are selected, only incident events in those channels trigger callbacks
Event Types	Check the event types to subscribe to (see Event Types); select all is supported. Only checked event types trigger callbacks

Disabling TLS certificate verification may expose you to man-in-the-middle attacks. Only disable it in test environments or when using self-signed certificates.

Custom request body

By default, the system pushes the complete JSON data following the Payload structure described above. If your receiver requires a specific data format, you can use a custom request body to reorganize the push content. Use {{field.path}} syntax to reference any field from the default Payload. The system replaces variables with actual values at push time. Variable syntax:

Use . to separate path levels, for example, {{incident.title}} references the incident title
Array index access is supported, for example, {{incident.responders.0.email}} references the first responder’s email
When the entire value is a single variable (for example, "{{incident.labels}}"), Flashduty keeps the original data type (object, array, number, and so on)
When a variable is mixed with other text (for example, "Incident: {{incident.title}}"), Flashduty converts the variable to a string and concatenates it

Example: Transform the default Payload into a custom format for an internal system:

{
  "msg_type": "incident",
  "event": "{{event_type}}",
  "content": {
    "id": "{{incident.incident_id}}",
    "name": "{{incident.title}}",
    "severity": "{{incident.incident_severity}}",
    "status": "{{incident.progress}}",
    "channel": "{{incident.channel_name}}",
    "url": "{{incident.detail_url}}",
    "labels": "{{incident.labels}}",
    "responders": "{{incident.responders}}"
  }
}

If a variable path does not exist in the default Payload, the system keeps the original {{...}} text without replacement. First check the actual default Payload through invocation history to confirm available field paths.

Value mapping (value_mapping)

In the custom request body, you may need to convert Flashduty field values to the format expected by the receiving system. Value mapping automatically transforms values during variable resolution. You configure value mapping per field path, with each path containing a source value → target value mapping table. Example: Convert severity and progress to custom values for the receiving system:

{
  "incident.incident_severity": {
    "Critical": "P0",
    "Warning": "P1",
    "Info": "P2"
  },
  "incident.progress": {
    "Triggered": "open",
    "Processing": "in_progress",
    "Closed": "resolved"
  }
}

Used with the following custom request body:

{
  "severity": "{{incident.incident_severity}}",
  "status": "{{incident.progress}}",
  "title": "{{incident.title}}"
}

When the incident severity is Critical, the severity field in the push result will be P0. Flashduty sends values that match no mapping as they are.

Invocation history

Incident Webhook provides a complete invocation history, helping you troubleshoot push delivery and debug callback interfaces.

View invocation history

Go to the Incident Webhook integration detail page and switch to the Invocation History tab.

Filtering and search

Filter	Description
Time Range	Select from last 1 hour, 6 hours, 1 day, 7 days, or custom range (up to 7 days of data)
Incident ID	Enter an incident ID for exact search
Event Type	Filter records by event type
Request Status	Filter by success or failure

History record fields

Field	Description
Trigger Time	Time when the event was triggered
Event Type	The triggered event type (for example, `i_new`, `i_ack` and so on)
Incident ID	Associated incident ID; click to jump to incident details
Event ID	Unique identifier for this callback; used for deduplication
Request Status	Success or failure, with HTTP status code
Duration	Round-trip request time
Attempt Count	Includes initial request and retries

View invocation details

Click View Details on a record to see the complete request and response information:

Request: Includes Endpoint, Request Headers, and Request Payload
Response: On success, shows Response Headers and Response Body; on failure, shows Error Message

FAQ

Is there a response timeout?
- Your service must respond within 2 seconds; Flashduty treats a slower response as a failure
Will pushes continue after failure?

Retries for specific network errors, max 1 retries:

context deadline exceeded (excluding awaiting headers)
i/o timeout
eof

How to ensure push order?
- Flashduty pushes events for the same incident in chronological order, but retries can deliver them out of order
- Services can filter based on event_time; after receiving a later event, they can drop earlier ones. Each push carries the latest complete information, so occasional event loss is tolerable
Trusted IP whitelist for push source?
- 47.94.95.118, 123.56.8.183, 47.94.193.81, and 1.13.19.96 (SaaS only; in a private deployment, pushes originate from your own environment’s egress address — check with your infrastructure team)
- We may update this list, so check it regularly

Quick Start

Product Comparison

Channels

Incident Management

Post-Mortem

Status Page

Analytics

Integration Settings

Configuration

Advanced

Integrations

Best Practices

Event types

Push description

Request method

Request payload:

Event details (event_detail)

Request response

Request example

Configuration guide

Basic settings

Webhook settings

Custom request body

Value mapping (value_mapping)

Invocation history

View invocation history

Filtering and search

History record fields

View invocation details

FAQ

​Event types

​Push description

​Request method

​Request payload:

​Event details (event_detail)

​Request response

​Request example

​Configuration guide

​Basic settings

​Webhook settings

​Custom request body

​Value mapping (value_mapping)

​Invocation history

​View invocation history

​Filtering and search

​History record fields

​View invocation details

​FAQ

Event types

Push description

Request method

Request payload:

Event details (event_detail)

Request response

Request example

Configuration guide

Basic settings

Webhook settings

Custom request body

Value mapping (value_mapping)

Invocation history

View invocation history

Filtering and search

History record fields

View invocation details

FAQ