Integrations
Alerts, cases and telemetry flow in and out of Wardex over well-documented protocols. Every built-in connector is configured from the admin console under Settings → Integrations.
Alerting & chat
Route alerts, case updates and runbook prompts to channels or DMs via incoming webhook.
Incoming-webhook adapter with Adaptive Card formatting.
Events API v2 with dedup keys per case ID.
Events API with priority mapping from severity.
Signed JSON POST with retries, suitable for any receiver.
Email alerts and weekly digests with TLS.
Ticketing & case management
Create/update issues with bidirectional state sync and custom-field mapping.
Table API connector for Security Incident Response.
For small teams running internal tracking in GitHub.
GraphQL mutations with project/team mapping.
SIEM & log pipelines
HTTP Event Collector sink with batching and backpressure.
Bulk API sink with ECS-mapped field names.
TLS and UDP transports, CEF and raw JSON payloads.
Export traces, metrics and logs to any OTLP receiver.
Native producer with SASL/SCRAM and TLS.
Cold archival of events and case artifacts with compression.
Integration Guide
Every connector needs explicit auth, payload ownership, and retry behavior. Treat the integration as part of the incident path, not a decorative add-on.
Store credentials in the integration config only long enough to test delivery, then rotate into the secret source you actually operate with.
Wardex connectors retry transient failures, keep dedup keys stable where the downstream API supports them, and write the integration attempt into the audit surface.
Decide once how severity, ownership, MITRE references, asset identity, and case URLs map into the downstream system, then keep that mapping stable across releases.
Setup Walkthrough
The goal is predictable delivery and predictable rollback. This is the shortest path that still leaves an audit trail.
Assign the person or team that owns the downstream endpoint, token, and escalation path before you paste credentials into the admin console.
Choose which severities send immediately, which cases create tickets, and whether the connector should mirror alerts, cases, or both.
Send a single controlled event or case update first. Validate the payload shape, timestamp formatting, and backlink into Wardex before enabling wide fan-out.
Decide what operators do if the connector is down: retry later, fall back to email, or continue case work only inside Wardex until the sink recovers.
Signed JSON payloads are the safest default when the downstream system has a custom receiver.
{
"case_id": "CASE-1042",
"severity": "high",
"status": "triage",
"title": "Suspicious shell spawned from Office",
"endpoint_id": "macbook-sec-17",
"rule": "office-child-process",
"mitre": ["T1204", "T1059"],
"wardex_url": "https://console.example/cases/CASE-1042"
}When forwarding to syslog or a SIEM collector, keep the normalized case identifiers and timestamps intact so correlation stays deterministic.
<134>1 2026-04-21T14:22:09Z wardex control-plane - - -
event.kind=alert event.id=CASE-1042 severity=high
endpoint.id=macbook-sec-17 rule=office-child-process
wardex.url=https://console.example/cases/CASE-1042Reference docs: Pair this page with the SIEM runbook, the OpenAPI contract, and the SDK guide when you build or debug a connector.
Identity & SSO
Works with Okta, Entra ID, Google Workspace, Authentik, Keycloak.
Enterprise federation for Azure AD / ADFS / PingFederate.
Automated user and group provisioning.
Threat intel
Pull indicators via REST and auto-attach to matching events.
Pull STIX feeds from any TAXII server (DHS AIS, OTX, commercial).
Hash and URL enrichment with per-tenant API keys.
IP reputation for external connections.
The integration layer is a stable Rust trait. Email the support mailbox with the downstream system, auth model, payload expectations, and urgency, or open a PR if you already know the implementation shape.