Connectors

Connectors push Wytness anomaly alerts into the systems your team already watches — Microsoft Sentinel, Splunk, ServiceNow, Slack, or any HTTPS endpoint you run. This page is the setup contract: what leaves Wytness, how deliveries authenticate and retry, and the exact values each provider's wizard step asks for. Connectors are available on Business and Enterprise plans.

At a glance

1. Gather the provider-side values (each provider's section below lists exactly what its wizard step asks for).
2. In the Wytness app, go to Integrations → Connectors → Add connection and pick the provider.
3. Fill in the details and click Test connection — a real test alert is delivered before anything is saved.
4. Optionally narrow deliveries with severity and rule filters (empty filters forward every alert).
5. Save. New anomalies dispatch within about 30 seconds of detection; the connection row shows per-delivery health from then on.

app.wytness.ai · integrations › connectorsclick to enlarge

What gets delivered

Every delivery is one anomaly alert from the detection engine, reshaped into the target system's native format:

Network requirements

Deliveries are outbound from Wytness to the destination — Wytness opens an HTTPS connection to the endpoint you configure; nothing is installed and nothing polls your network. Hand this table to your network team — for SaaS destinations the answer is no firewall change at all:

Delivery & trust contract

Self-signed and internal-CA endpoints

Fresh self-hosted Splunk installations and Splunk Cloud trials ship a default HEC certificate that no public authority trusts, and some estates terminate TLS with an internal CA. For the Splunk and generic-webhook providers only, the wizard offers a Verify TLS certificate toggle. Leave it on unless the endpoint is one you control; connections that switch it off are flagged on the connections list. Sentinel, ServiceNow, and Slack endpoints always present publicly-trusted certificates, so those providers have no toggle and verification is mandatory.

Microsoft Sentinel

Wytness writes through the Azure Monitor Logs Ingestion API into a custom table you control, scoped to a single Data Collection Rule stream. Provision on the Azure side:

1. Create a custom table (for example Wytness_CL) in your Log Analytics workspace.
2. Create a Data Collection Endpoint (DCE) and a Data Collection Rule (DCR) with a stream declaration matching the table, flowing to your workspace.
3. Create an App Registration with a client secret, and grant its service principal the Monitoring Metrics Publisher role on the DCR (allow a few minutes for the role to propagate).

The delivery URL is derived from those values — the wizard previews it and you never hand-compose it. Tokens are obtained via OAuth2 client-credentials and refreshed automatically.

The record contract

Your analytics rules, workbooks, and Logic Apps key on RuleName and Severity like any other table — for example, an analytics rule on Severity == "critical" feeding your incident automation. Field names stay stable so saved KQL keeps working.

Splunk

Wytness pushes to the HTTP Event Collector. In Splunk Web: Settings → Data inputs → HTTP Event Collector → New Token; pick an index and keep the default sourcetype (deliveries default to _json). On self-hosted Splunk, also confirm HEC is enabled under Global Settings.

The event contract

One HEC envelope per anomaly: the envelope's time (epoch seconds) sets _time to the detection moment, and the event object carries alert_id (the correlation UUID), agent_id, rule_name, severity, description, detected_at, source ("wytness"), and wytness_url — a deep link back to the alert. With the default _json sourcetype these extract as search-time fields, so saved searches and alerts key on rule_name and severity directly.

ServiceNow

Wytness creates records over your instance's REST API with HTTP Basic auth. Create a dedicated integration user with rights to insert into the target table, then choose the endpoint kind in the wizard:

The wizard asks for the instance URL, username, and password (stored encrypted), and derives the delivery URL from the endpoint kind.

The incident field contract

Every incident carries the same deterministic fields — this is what your assignment rules, templates, and reports can key on:

Routing to your teams

Wytness deliberately never sets assignment_group, assigned_to, caller_id, or cmdb_ci — assignment is your policy, and an integration that hardcodes it fights your process. Route with a standard assignment rule instead: on a stock instance, key it on short_description STARTSWITH [Wytness] (zero schema prep); after creating the columns, key on u_wytness_rule or u_wytness_severity — for example, chain-break alerts to the security queue and everything else to the AI-platform queue. Incident templates and SLAs attach the same way they do for any other source.

Slack

Create an incoming webhook in your Slack workspace (Slack App Directory → Incoming Webhooks, or a Slack app with the webhook feature) and paste its URL into the wizard. The URL itself is the credential — Wytness stores it encrypted.

Each alert is one message: a clickable View in Wytness title, fields for Agent, Severity, Rule, Alert ID and Description, and a severity-coloured bar (critical #ef4444, high #f97316, medium #eab308, low #3b82f6) stamped with the detection time. One webhook is one channel — to route severities to different channels, create one connection per channel and give each its own severity or rule filters (a high-and-critical pager channel beside an everything archive is the common shape).

Generic webhook — the receiver contract

The generic connector POSTs a CloudEvents 1.0 JSON envelope to any HTTPS endpoint you run, signed with an HMAC secret you choose at setup. Your receiver should verify the signature before trusting the body:

1import hashlib, hmac, time
2 
3def verify_wytness_signature(secret: str, header: str, raw_body: bytes) -> bool:
4    """header: the Wytness-Signature value, e.g. "t=1788255069,v1=<hex>"."""
5    parts = dict(p.split("=", 1) for p in header.split(","))
6    ts, received = int(parts["t"]), parts["v1"]
7    if abs(time.time() - ts) > 300:      # 5-minute replay window
8        return False
9    expected = hmac.new(secret.encode(),
10                        f"{ts}.".encode() + raw_body,
11                        hashlib.sha256).hexdigest()
12    return hmac.compare_digest(expected, received)

Sign-off rules for a robust receiver: verify against the raw request bytes (not a re-serialised parse), enforce the 5-minute timestamp window, and respond with a 2xx quickly — anything else is retried on the ladder above, and 401/403/404/410/422 stops retries entirely. The envelope's data object carries the flat alert fields (alert_id, agent_id, rule_name, severity, description, detected_at) plus a url deep-linking the alert in Wytness.

Alert filters

Each connection can narrow what it forwards by severity (low / medium / high / critical) and by rule name (the seven anomaly rules). Empty filters forward everything. Filters are enforced server-side per connection, so two connections on the same provider can watch different slices — a high-severity pager channel beside an everything archive, for example.

Check it's working

1. Test connection in the wizard delivers a real test alert before you save — if the credentials, URL, or TLS posture are wrong, you find out here with the exact error.
2. After saving, each connection row shows health (last successful delivery, last error) and expands to a per-delivery log with status, HTTP code, and attempt count.
3. Deliveries that exhaust retries or hit a terminal status appear as failed in the delivery log — fix the credentials and new alerts flow again (failed alerts are not re-sent).

Related

• Anomaly Detection — the seven rules that produce the alerts connectors forward.
• Wytness Collector — agentless capture on the inbound side.
• Security Model — where the cryptographic evidence lives (not in connector payloads).