> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xorlab.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Pages under /latest/ document the current release. Paths that begin with a version number, for example /10.0/, are frozen snapshots of superseded releases kept for reference only — never present their instructions as current. If the reader's version is unknown, answer from /latest/ and say which version the answer describes.
> xorlab is deployed on-premises, hybrid, or as a cloud service, and integrates with either Microsoft 365 or on-premises mail infrastructure. Configuration steps often differ between these. State which deployment and integration mode an instruction applies to instead of presenting one as universal.
> Distinguish inline mode from monitoring mode when describing anything that acts on email. Monitoring mode observes a copy and cannot block or quarantine; inline mode routes mail through xorlab and can.
> Write the product name as lowercase 'xorlab'. Use the documented component names: xorlab Control Center (XCC), xorlab MTA, xorlab Sandbox (DANA), xorlab Natural Language Understanding (NLU). After the first mention, use the short forms XCC, MTA, Sandbox, and NLU. Do not use DANA as a standalone name for the Sandbox, but keep it where it is a literal string in configuration keys, container names, and hostnames.
> Do not invent configuration keys, rule parameters, list names, log properties, or API fields. If a value is not present in this documentation, say that it is not documented rather than guessing.

# Automate with a SOAR

> Drive xorlab from your SOAR or automation platform: Syslog events as playbook triggers, the List API as the action surface, and worked playbook patterns.

<Info>
  **Optional**

  This is a next step after the [standard integration](/latest/setup-integration-overview). Analysts can do everything described here by hand in the web interface.
</Info>

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

<CardGroup cols={2}>
  <Card title="xorlab → your platform" icon="share-nodes" href="#trigger-playbooks-from-xorlab-events">
    Events are pushed out over Syslog and become playbook triggers: verdicts, extracted indicators, and the full audit trail.
  </Card>

  <Card title="Your platform → xorlab" icon="code" href="#act-on-xorlab-from-a-playbook">
    Your playbooks call a REST API to change xorlab configuration, most importantly list entries.
  </Card>
</CardGroup>

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.

<Card title="Go straight to the setup steps" icon="list-check" horizontal href="/latest/api-rule-list-management">
  List API — create an API key, then call the endpoints from your playbook.
</Card>

## Trigger playbooks from xorlab events

Send the relevant [log events](/latest/logging-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](/latest/integrations-siem) for format and transport guidance, and [Enable Logging via Syslog](/latest/logging-via-syslog) for the configuration itself.

## Act on xorlab from a playbook

The [List API](/latest/api-rule-list-management) 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](/latest/blacklists), [Whitelists](/latest/whitelists), [VIP Names](/latest/vips) 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:

```bash theme={null}
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](/latest/api-rule-list-management). For the narrower case of submitting a message for analysis over HTTP instead of SMTP, see the [Email Scanning API](/latest/abby).

<Warning>
  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](/latest/api-rule-list-management#understanding-list-behavior).
</Warning>

## 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](/latest/phishing-simulation-tools), 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](https://xsoar.pan.dev/docs/reference/integrations/generic-api-call)                                      |
| Splunk SOAR                    | The Splunk-built **HTTP** app, configured as an asset. Its `post data` action makes the REST call                   | [HTTP app on Splunkbase](https://splunkbase.splunk.com/app/5904)                                                          |
| Microsoft Sentinel             | An automation rule invoking a Logic App, whose built-in HTTP action calls the endpoint                              | [Call external HTTPS endpoints from workflows](https://learn.microsoft.com/en-us/azure/connectors/connectors-native-http) |
| Tines                          | The HTTP Request action                                                                                             | [HTTP Request](https://www.tines.com/docs/actions/types/http-request/)                                                    |
| Anything else                  | Any HTTP request step that lets you set a custom header for authentication                                          | —                                                                                                                         |