Set Company Webhook

Set or clear the webhook configuration for an existing company. Send webhook: null to clear it; otherwise webhook.url and webhook.token are both required.

If the authenticated user belongs to an organization with synced_data: true, only the user with organization.role: "owner" can call this endpoint. Other members receive 403 Forbidden.

Webhook delivery reference

1. Event types: standard alert vs. data_alert

Each company's webhook works in one of two modes. The modes don't run together; data_alert replaces the standard alert. Every event is an infostealer compromise that matched that company's monitored assets. Apart from test events you trigger yourself (see Testing below), we don't send any other event types, such as ping events.

• Standard (data_alert: false): one summary event per company per notification run. It contains counts per monitored domain and no credentials. sourcetype is hudsonrock:alert.
• Data alert (data_alert: true): one event per compromised machine per match category. It contains the full record for that machine. sourcetype is hudsonrock:data.

2. Payload structure

The body is JSON in a Splunk HEC-style envelope: {"event": {...}, "sourcetype": "..."}. Dates and IDs use MongoDB Extended JSON ({"$date": "<ISO-8601>"} and {"$oid": "<id>"}).

Standard alert:

{
  "event": {
    "Example Corp": {
      "example.com": {
        "employees": 2,
        "third_party": 1,
        "externals": 0,
        "clients": 14,
        "apps": 0,
        "supply_chain": 0
      },
      "example.net": {
        "employees": 0,
        "third_party": 0,
        "externals": 0,
        "clients": 0,
        "apps": 0,
        "supply_chain": 0
      }
    },
    "earliest_timestamp": 1760486400
  },
  "sourcetype": "hudsonrock:alert"
}

Every monitored domain of the company is listed, including domains with zero counts. earliest_timestamp is the Unix time when we ingested the earliest record in this batch. It is not the compromise date.

Data alert (anonymized):

{
  "event": {
    "category": "employee",
    "stealer": {
      "_id": {
        "$oid": "6710c2a8f1d3b2a9e4c01234"
      },
      "version": "1.0",
      "stealer": "US_203.0.113.24_2026_10_12_08_14_31",
      "stealer_family": "Lumma",
      "date_compromised": {
        "$date": "2026-10-12T08:14:31Z"
      },
      "employeeAt": [
        "example.com"
      ],
      "clientAt": [
        "github.com",
        "microsoft.com"
      ],
      "data": {
        "ip": [
          {
            "source": "information.txt",
            "data": "203.0.113.24"
          }
        ],
        "OS": {
          "source": "information.txt",
          "data": "Windows 10 Enterprise [x64]"
        },
        "comp_name": {
          "source": "information.txt",
          "data": "EXAMPLE-LT-0412"
        },
        "malwarePath": [
          {
            "source": "information.txt",
            "data": "C:\\Users\\jdoe\\AppData\\Local\\Temp\\setup.exe"
          }
        ],
        "antiviruses": [
          "Windows Defender"
        ],
        "local_time": [
          {
            "source": "information.txt",
            "data": "2026-10-12 08:14:31"
          }
        ],
        "softwareData": [
          {
            "program": "Google Chrome",
            "version": "129.0.6668.90"
          }
        ],
        "cookieInsights": [
          {
            "url": "portal.example.com",
            "url_stripped": "example.com",
            "cookie_name": "session",
            "value": "..."
          }
        ],
        "credentials": [
          {
            "type": "employee",
            "data": {
              "url": "https://sso.example.com/login",
              "login": "j.doe@example.com",
              "password": "...",
              "url_stripped": "example.com",
              "android": false
            }
          }
        ]
      }
    }
  },
  "sourcetype": "hudsonrock:data"
}

category is one of employee, third_party, client, app or external. A machine that matches more than one category produces one event per category.

3. Content and masking

• Credentials: each event includes only the credentials that matched this company's assets in that category.
• Employee and third_party events: these also carry the machine's full context: IP, OS, computer name, malware path, antivirus, local time, installed software, cookie insights, and the employeeAt/clientAt domain lists.
• Client, app and external events: machine info is limited to IP, OS, computer name, antivirus and malware path.
• Masking: no data is masked. Passwords and cookie values are delivered in clear text, so please treat the receiving endpoint and SIEM index as sensitive.

4. Tenant identification

Each per-company webhook receives only that company's data.

• Standard alerts are keyed by company name and domain.
• Data alerts don't currently include the company ID or name. The matched domain is in credentials[].data.url_stripped, and in employeeAt for employee events.

If several companies share one endpoint, we recommend a distinct URL per company, for example https://soar.example.org/hudsonrock?tenant=<companyId>, or a distinct token per company. Both are configured per company, so your side can attribute every request.

5. Delivery behavior

• Batching: standard mode sends one event per company per run. Data mode sends one HTTP request per event, so events aren't batched.
• Frequency: a run starts once new data has finished ingesting. In practice this can range from not a single notification to several times a day.
• Size: there's no fixed maximum. Data events grow with the number of matched credentials and the machine's software and cookie inventory, so please make sure your endpoint accepts bodies of at least a few MB.

6. Reliability

• Request: HTTPS POST with Content-Type: application/json.
• Authentication: the token you configured is sent exactly as entered in the header named by auth_header (default Authorization). Include any scheme yourself, e.g. Bearer <token> or Splunk <token>. Requests aren't signed beyond this header.
• Success: any 2xx response counts as delivered. We don't read the response body.
• Retries: connection failures are retried twice, immediately. A non-2xx response isn't retried. Undelivered events are flagged to our team and can be re-sent manually on request.
• Timeout: we don't currently apply a fixed timeout. Please acknowledge with a 2xx right away and process asynchronously.

7. Testing

Before going live, call POST /companies/{companyId}/webhook/test to send a single test event to your receiver. It uses the same envelope, sourcetype, headers and token as real deliveries, so you can validate authentication, parsing and SIEM routing end to end. Test events carry "test": true inside event, contain only placeholder data, and report zero counts, so you can filter them out of production rules. See that endpoint for details.