Webhook Payload Reference

When an Action fires the Custom Webhook automation, Protect issues an outbound HTTP request to the URL you configured. This page is the canonical reference for what that request looks like. For symptom-driven debugging (webhook timeouts, 4xx / 5xx responses) see Troubleshooting → Action Center. For the configuration UI itself see Automation.

Request shape

Property	Value
Method	`POST` by default. The Webhook configurator also exposes `PUT` and `PATCH` in the method dropdown.
Content-Type	`application/json; charset=utf-8`
Body	A JSON object describing the Action and the devices that triggered it (see Body shape below).
Custom headers / query params / body fields	Optional key/value rows defined per-Action in the Webhook configurator.
Timeout	A destination that doesn’t respond in time is logged as `Webhook timeout` in the Automation Log.

The destination URL is supplied per-Action when you choose the Custom Webhook automation type. The configurator surfaces:

Method dropdown — POST, PUT, PATCH
Request URL field
Request Headers table (Key / Value rows)
Query Params table (Key / Value rows)
Body table (Key / Value rows)
Test Webhook section — fires a test request using one of three data sources: Demo Data, Sample Data, All Data

Body shape

The default body is a JSON object with the following top-level keys:

{
  "id": "00fda7c0-9cc5-47ff-8341-c4a85fc4e328",
  "viewId": "temp-7333ccf3-7215-4026-af40-0d5168bf4dda",
  "name": "Docs Webhook Test (delete me)-c20d97a8-1f8c-4e37-90fd-6318e0f9e58b",
  "description": "",
  "triggerTime": "2026-05-22T08:25:35.6802447Z",
  "newDevices": [
    { "Name": "BSG-001-09DAO" },
    { "Name": "BSG-001-0BB46" },
    { "Name": "BSG-001-0HNWP" }
  ]
}

Key	Meaning
`id`	UUID of the firing — unique per request. Use this for de-duplication on the receiver.
`viewId`	UUID of the underlying saved view (or `temp-…` prefix for inline / unsaved test views).
`name`	Action name. For test requests, suffixed with a UUID.
`description`	Action description (often empty).
`triggerTime`	ISO-8601 timestamp of when the firing was generated.
`newDevices`	Array of objects representing devices that triggered this firing. Each object’s keys are the fields configured on the Action’s Body table (default: `Name`).

The newDevices[].* field set is what you configure under the Body table on the Action, not a fixed shape. Adding rows to the Body table extends each device object with additional fields (e.g. Os, LastUser.Email). Demo Data uses a fixed sample of device names; Sample Data uses the first matching devices from the saved view; All Data sends every matching device in a single request.

Body template interpolation

The Body table is a Key / Value mapping. The Value column supports literal strings, and for fields surfaced by the Action editor’s field picker (the small dropdown next to each Value cell), Protect interpolates the matching device field at fire time. Common interpolation fields used in Body values:

Field	Example value
`Name` (device name)	`LAPTOP-AB12CD`
`Os`	`Windows 11`, `macOS 14`, `Ubuntu 22.04`
`PublicIp`	`203.0.113.42`
`LastOnline`	ISO-8601 timestamp
`LastUser.Email`	`user@example.com`
`LastUser.Name`	`Jane Doe`

Headers

Default headers sent on every webhook:

Header	Value
`Content-Type`	`application/json; charset=utf-8`
`User-Agent`	`RestSharp/<version>`
`Accept`	`application/json, text/json, text/x-json, text/javascript, application/xml, text/xml`
`Accept-Encoding`	`gzip, deflate, br`
`Cache-Control`	`no-cache`
`Content-Filtertype`	`application/json`
`Content-Length`	Computed per-request

Custom headers configured on the Action are sent in addition to the defaults. Typical custom headers include:

Authorization: Bearer <token> for destination-side authentication
X-API-Key: <key> for systems that use a custom auth header
X-Source: protect or similar for downstream routing

Protect does not add a signature header (such as an HMAC X-ThreatAware-Signature) to outbound webhooks. To authenticate the source on your receiver, add an Authorization or X-API-Key header to the Action’s Request Headers table.

Retry behaviour

When a destination returns a non-2xx response or times out:

Failure is logged in the Action’s Automation Log with the response status (or timeout)
Retries are attempted automatically for transient failures (5xx, network errors)
4xx responses are typically treated as terminal — the destination rejected the payload and retrying won’t help

The current state and history of every webhook execution is visible in the Automation Log on the Action Center page. Filter by Action to surface persistent issues.

Webhook destinations

Protect’s Action Center exposes the following automation types from the Create Action modal:

Channel	Notes
Trigger Workflow	Run a pre-built workflow (e.g. ServiceNow incident, Crowdstrike isolate)
Create Ticket	Open a ticket via an integrated ITSM (ServiceNow / Halo / Jira)
Send Notification	In-product notification
Send Email	Send to one or more email recipients
Custom Webhook	Generic `POST` / `PUT` / `PATCH` to any URL — Tines, Demisto, AWS Lambda, internal APIs, etc.

This page documents the Custom Webhook wire format. The other channels (Trigger Workflow, Create Ticket, Send Notification, Send Email) use destination-specific transports.

Testing your endpoint

Open the Custom Webhook configurator

Action Center → Create Action → choose Custom Webhook under Automations.

Point at a request bin

Use a free request inspector (e.g. webhook.site, requestbin.com) to capture the exact headers and body Protect sends.

Use the Test Webhook section

Pick a Type (Demo Data / Sample Data / All Data) and click Send Test Request — this fires without saving the Action.

Watch the Automation Log

The Automation Log on the Action Center page records the response code and any retries for live (non-test) firings.

Security considerations

Authenticate the destination

Protect doesn’t sign webhook requests and doesn’t restrict where they go. Configure your destination to require an Authorization header (set as a custom Request Header on the Action) and reject unauthenticated requests.

Allowlist ThreatAware egress

For destinations behind a firewall, allowlist the ThreatAware egress IP range — request the current list from your account team.

Treat the device payload as sensitive

Payloads include the device hostname, user email, public IP, and any custom fields you’ve added. Log accordingly — don’t write to public storage.

Rotate destination credentials

Auth tokens embedded in custom headers are stored as part of the Action configuration. Rotate them on a normal cadence and re-save the Action when you do.

Cross-references

Action Center

The conceptual home of webhook automations

Continuous Actions

Always-on Actions

Snapshot Actions

Time-bound Actions

Error Codes

Action error states

Troubleshooting

Webhook failure debugging

API Reference

Inbound API counterpart

ThreatAware Protect

Getting Started

Inventory

Tags & Logic Engine

Vitals & Issues

Action Center

Integrations

Reporting

Access & Admin

Reference

Trust & Security

Webhook Payload Reference

Request shape

Body shape

Body template interpolation

Headers

Retry behaviour

Webhook destinations

Testing your endpoint

Security considerations

Cross-references

Action Center

Continuous Actions

Snapshot Actions

Error Codes

Troubleshooting

API Reference

​Request shape

​Body shape

​Body template interpolation

​Headers

​Retry behaviour

​Webhook destinations

​Testing your endpoint

​Security considerations

​Cross-references

Action Center

Continuous Actions

Snapshot Actions

Error Codes

Troubleshooting

API Reference

Request shape

Body shape

Body template interpolation

Headers

Retry behaviour

Webhook destinations

Testing your endpoint

Security considerations

Cross-references