Automate with a SOAR

OptionalThis is a next step after the standard integration. Analysts can do everything described here by hand in the web interface.

You can operate xorlab by machine as well as by hand. Automation runs in two directions:

xorlab → your platform

Events are pushed out over Syslog and become playbook triggers: verdicts, extracted indicators, and the full audit trail.

Your platform → xorlab

Your playbooks call a REST API to change xorlab configuration, most importantly list entries.

Both use interfaces most SOAR and automation platform already supports, so integrating xorlab is a matter of configuring a Syslog source and an HTTP action.

Go straight to the setup steps

List API — create an API key, then call the endpoints from your playbook.

Trigger playbooks from xorlab events

Send the relevant log events over Syslog to your SOAR, or to the SIEM your SOAR is already connected to. The events most often used as triggers:

Trigger	Event	Typical playbook
An email was quarantined or blocked	`trace.msg_verdict`, `trace.msg_analysis.complete`	Open or enrich a case, notify the recipient’s manager, check whether the same sender reached other systems.
A malicious indicator was observed	`ti.email`, `ti.ip`, `ti.file`, `ti.domain`, `ti.url`	Push the indicator to the proxy, firewall, or EDR blocklist, and hunt for it across other log sources.
A user released a message from quarantine	`audit.user.quarantine_release`	Post-hoc review of the release, and follow-up if the message was high risk.
A release request was created	`audit.quarantine.release.request.created`	Route the approval into your ticketing or chat workflow.
An analyst isolated an email	`audit.isolate.removed`	Record the containment action in the incident record.
A list or configuration changed	`audit.user.lists.item_added`, `audit.user.lists.item_removed`, `audit.user.config.file_modified`	Change-management evidence, and alerting on unexpected changes.

Setup is the standard Syslog path — see Connect a SIEM for format and transport guidance, and Enable Logging via Syslog for the configuration itself.

Act on xorlab from a playbook

The List API is the primary automation surface. It reaches every list that is visible in the web interface, including custom lists. That covers most of what a playbook needs to change: Blacklists, Whitelists, VIP Names and high-value targets, fraud keywords, simulation senders, trusted infrastructure, and reporting addresses.

Endpoint	Use
`getLists`	Discover the available lists, their internal names, and their `maxSize`. Always start here.
`listEntries`	Read the current entries of a list, as NDJSON.
`addEntries`	Add or update entries, each with a free-text comment.
`deleteEntries`	Remove entries. Missing entries are ignored, so calls are safe to repeat.

Use this minimal action step to add a sender domain your playbook has confirmed as malicious to a Blacklist:

curl -sS -X POST \
  '<xorlab-url>/api/public/lists/v1/addEntries' \
  -H 'Authorization: apikey <api-key>' \
  -H 'Content-Type: application/json' \
  -d '{
    "tenantUid": null,
    "listName": "BLACKLIST_local_sender_addresses",
    "entries": [
      {
        "entry": "bad-domain.example",
        "comment": "Blocked by playbook PB-114, case INC-4821"
      }
    ]
  }'

Use the comment field deliberately. Analysts see it on the Lists page, so it is the fastest way for them to understand why an automated entry exists. Put the playbook name and the case ID in it. For the API key, the endpoint reference, and multi-tenant scoping, see the List API. For the narrower case of submitting a message for analysis over HTTP instead of SMTP, see the Email Scanning API.

Every list has a maximum size, and adding to a full list removes its oldest entry. An unbounded automation that keeps adding entries will therefore evict older ones. Read maxSize from getLists and have your playbook clean up its own entries with deleteEntries, for example when a case is closed. See Understanding list behavior.

Playbook patterns

Common patterns:

Pattern	How it works
Close the loop on a confirmed phishing case	An analyst or a playbook confirms a reported email is malicious → `addEntries` puts the sender address or domain on a Blacklist → the indicator also goes to the proxy and EDR.
Sync an external feed or deny list	A scheduled playbook reads your authoritative source (threat feed, MISP, an internal deny list) and reconciles it into a xorlab list with `listEntries`, `addEntries`, and `deleteEntries`.
Keep VIP data in step with HR	On a change in the HR system or an Entra ID group, update the VIP names and high-value-target lists so impersonation protection follows the org chart automatically.
Onboard a phishing simulation campaign	Before a campaign starts, a playbook adds the simulation provider’s sending IP range to the Simulation lists, and removes it when the campaign ends.
Time-boxed exceptions	A playbook adds a Whitelist entry with a case ID in the comment and schedules its own `deleteEntries` call, so temporary exceptions do not become permanent ones.
Enrich tickets with the xorlab verdict	The verdict event forwarded over Syslog carries the decision, tags, sender authentication result, and attachment hashes. That is enough to populate a ticket without anyone opening xorlab.

Platform notes

The xorlab side is identical for every platform: a Syslog destination for events, and an authenticated HTTP POST for actions. The table below names the building block to use on the other side, and where the vendor documents it.

Platform	Building block	Vendor documentation
Palo Alto Cortex XSOAR / XSIAM	The GenericAPICall integration, which makes authenticated HTTP calls to endpoints without a dedicated integration	GenericAPICall
Splunk SOAR	The Splunk-built HTTP app, configured as an asset. Its `post data` action makes the REST call	HTTP app on Splunkbase
Microsoft Sentinel	An automation rule invoking a Logic App, whose built-in HTTP action calls the endpoint	Call external HTTPS endpoints from workflows
Tines	The HTTP Request action	HTTP Request
Anything else	Any HTTP request step that lets you set a custom header for authentication	—

xorlab → your platform

Your platform → xorlab

Go straight to the setup steps

​Trigger playbooks from xorlab events

​Act on xorlab from a playbook

​Playbook patterns

​Platform notes

Trigger playbooks from xorlab events

Act on xorlab from a playbook

Playbook patterns

Platform notes