Skip to main content
The Generic Detection integration turns any system that can send an HTTPS POST — a SIEM, an internal tool, a script, or another security product — into a detection source for Wirespeed. You send one detection per request in the documented JSON format, and Wirespeed triages it like a detection from any other integration: assets are extracted, the detection is categorized with the category you supply, and it appears in Detections and in the SIEM. This is the integration to use when your system already produces finished detections. If you want Wirespeed to find detections in raw log data instead, use Generic JSON or a dedicated integration for your product.

Setup in Wirespeed

  1. Login to Wirespeed and navigate to Integrations > Add Integration > Generic Detection
  2. Enter a Source Name to identify this sending system (for example, Internal SIEM)
  3. Optionally turn on Authentication (see Authentication)
  4. Click Integrate
  5. Select Webhook Details
  6. Copy the Webhook URL and, if you enabled authentication, the Webhook Secret
The Webhook URL has the form:
Create one Generic Detection integration per sending system. Each integration has its own URL, its own optional secret, and its own Source Name, so deliveries stay attributable and one system’s secret can be rotated without affecting another.

Authentication

Authentication is optional and off by default. When Authentication is on, every request must include the integration’s webhook secret in the X-Webhook-Key header:
Requests with a missing or incorrect key are rejected with 401 and the rejection is written to the integration’s log (at most once every five minutes, so a misconfigured sender cannot flood the log). The secret is never accepted in the URL or the request body.

Rotating the secret

  1. Open the integration’s Webhook Details
  2. Click Rotate secret
  3. Update the sender with the new secret
The old secret stops working as soon as the rotation completes. There is no grace period, so update the sender promptly; deliveries sent with the old secret in the meantime are rejected with 401 and are not queued.

Sending a detection

Send one detection per POST request with a JSON body:
Omit the X-Webhook-Key header if you did not enable authentication. A 200 response means the detection was accepted and queued; it does not wait for triage to finish.

Payload reference

Unknown fields are rejected, including inside assets, so a typo fails the request instead of being silently dropped.

Assets

Assets tell Wirespeed which users, endpoints, files, or IP addresses the detection is about, so it can correlate the detection with your inventory. Users, endpoints, and files can also be contained if needed; IP addresses are used for correlation only. Send as many as the detection involves — up to 50 of each type in one request. Send only the fields you know: each user, endpoint, or file asset needs at least one of its fields, and each IP asset needs address. Hashes are case-insensitive and are stored lowercase. A hash with the wrong length or non-hex characters fails the request. Send each IP address as a bare address. A port (203.0.113.7:443), a CIDR range (10.0.0.0/8), or a hostname fails the request; send hostnames as endpoints instead. IPv6 addresses are stored lowercase.

Categories

Pick the one category that best describes the detection. The list is deliberately short; for a suspicious detection, send the closest category. Use OTHER__INFORMATIONAL_EVENT only for activity that needs no response, because Wirespeed closes those detections as benign automatically. Category values use the standard Wirespeed category format: uppercase segments joined by double underscores. For example, IDENTITY__LOGIN has two underscores between IDENTITY and LOGIN — IDENTITY_LOGIN and identity-login are not accepted.

Sample payloads

Endpoint malware with a file asset

Network connection with IP address assets

Minimal payload

Only the required fields. Wirespeed can triage this, but adding an id and asset identifiers improves deduplication and correlation.

Errors and edge cases

Rejected deliveries are never queued. When a delivery fails validation, the reason is written to the integration’s log in Wirespeed so you can fix the sender; check there first when detections do not appear. Edge cases to know:
  • One detection per request. Send an array and the request fails validation; loop over detections instead.
  • Retries are safe with an id. The same id delivered twice becomes one detection. Without an id, a retry can create a duplicate.
  • Future timestamps are clamped to the ingestion time for the detection’s event time; the timestamps you sent are kept on the SIEM row.
  • Disabled integrations reject deliveries until they are re-enabled.
  • Secrets in URLs are ignored. A webhookSecret query parameter does not authenticate a request; use the X-Webhook-Key header.

What Wirespeed does with it

Each accepted delivery becomes one first-class Wirespeed detection, the same as a detection from any built-in integration, and is triaged automatically: Wirespeed investigates it, reaches a verdict, and escalates or responds according to your team’s automation settings, with no manual step needed. The users, endpoints, and files you sent are extracted for correlation and containment, the IP addresses for correlation, the detection is categorized with the category you sent, and the normalized payload is written to the generic_detection_logs SIEM table. In the SIEM you can filter that table by severity, category, and source; rows are stored ordered by team, then source, then time, so source-filtered queries stay fast. Each Generic Detection integration also appears as its own SIEM source under its Source Name, so deliveries from different sending systems stay separate even though they share one table.