The email-security industry has a short answer when asked "does this integrate with my SIEM?". The answer is usually "yes, we have a webhook". That answer is not a lie. It is also not an integration.
A webhook is an HTTP POST from one system to another carrying a JSON payload. Any two systems on the internet can speak webhook. It tells you that something happened. It does not give you detection rules, search optimisation, or index-time event classification. A SIEM connector is the opposite shape: a vendor-specific ingest pipeline that emits events in the shape a SIEM understands natively, pre-indexed, pre-typed, pre-ready for the rules engine.
The economic argument
For an MSP managing fourteen tenants on three different SIEM vendors, the webhook path means fourteen parsers, fourteen mapping tables, and fourteen on-call rotations for when a parser silently fails. A SOC engineer who writes a detection rule against the webhook shape is writing a rule that breaks when the vendor updates the JSON. The engineering debt compounds.
The connector path collapses that into configuration. One button per tenant, three supported shapes, and the parser lives inside the connector, not inside the customer.
What we shipped
Three native connectors, one for each of the dominant SIEM platforms, with event shape pre-mapped to the SIEM's native schema. Per-tenant endpoint configuration, so two tenants under the same MSP can target two different SIEM vendors without shared secrets.
A dead-letter queue sits behind every connector. Events that fail delivery retry on exponential backoff and, on eventual failure, land in a durable admin-visible queue with manual replay. The DLQ is the feature nobody asks about until an eight-hour downstream outage happens and they realise their events went to /dev/null.
Retries handle transient failure. A DLQ handles policy failure — when the downstream SIEM is intentionally offline, or when authentication rotates, or when the customer's SOC is mid-migration. A silent event loss during a planned maintenance window is worse than a loud retry failure.
What we did not ship
A universal parser. We considered it. A universal event shape that maps to every SIEM via plugin looks clean in a diagram. In practice it produces mappings that are 80% correct, with the 20% landing in different field positions per vendor. The SOC engineer ends up writing adapter rules to compensate, which is exactly what we were trying to eliminate.
We also did not ship a visual rule designer. The SIEM platforms each have their own, and our value is the event quality at ingest, not the rule authoring experience.
The boring details that matter
Event timestamps are emitted in RFC 3339 with timezone preserved. UTC-zero-offset is a common trap — it looks fine in the connector but produces a six-hour offset when the SIEM is indexing in local time.
Schema versioning is explicit in every event. A future schema migration can be rolled out per-connector without breaking the tenant's existing rules, because the SIEM can key on the schema version.
Connector health is surfaced to the admin portal with last-successful-delivery timestamps and a 24-hour error histogram. If a tenant's SIEM is quietly dropping events, their admin sees it before the next incident does.
SIEM integration is a boring feature done well. When it works, nobody notices. When it does not, every other part of a security operation gets harder. We chose to do it well.