> ## Documentation Index > Fetch the complete documentation index at: https://docs.threataware.com/llms.txt > Use this file to discover all available pages before exploring further. # Webhook Payload Reference > Outbound webhook payloads from Action automations — headers, body shape, retry behaviour When an [Action](/automation) 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](/reference/troubleshooting#action-center). For the configuration UI itself see [Automation](/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](#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: ```json theme={null} { "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/` | | `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 ` for destination-side authentication * `X-API-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 Action Center → Create Action → choose Custom Webhook under Automations. Use a free request inspector (e.g. `webhook.site`, `requestbin.com`) to capture the exact headers and body Protect sends. Pick a `Type` (Demo Data / Sample Data / All Data) and click **Send Test Request** — this fires without saving the Action. The Automation Log on the Action Center page records the response code and any retries for live (non-test) firings. ## Security considerations 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. For destinations behind a firewall, allowlist the ThreatAware egress IP range — request the current list from your account team. Payloads include the device hostname, user email, public IP, and any custom fields you've added. Log accordingly — don't write to public storage. 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 The conceptual home of webhook automations Always-on Actions Time-bound Actions Action error states Webhook failure debugging Inbound API counterpart