SIEM webhooks

Tenvyr can deliver audit batches to tenant-owned HTTPS destinations. Deliveries are CloudEvents with an NDJSON body and an ECDSA P-256 signature produced by the isolated audit exporter.

There is no shared webhook secret. Receivers verify signatures with authenticated public keys returned by Tenvyr.

Receiver requirements

The destination must:

• use an exact https:// URL on port 443;
• resolve through public DNS to public addresses;
• have no URL credentials, query string, or fragment;
• reject redirects;
• accept application/x-ndjson; and
• return a 2xx response quickly after durable receipt.

IP literals, internal-only names, custom ports, and redirects are rejected.

Pin verification keys

Before enabling delivery:

1. open Integrations → Receiver verification keys;
2. retrieve the active and overlap P-256 keys;
3. record each complete KMS key ID and public key through a channel independent of webhook delivery;
4. pin the keys in the receiver; and
5. keep overlap keys available until Tenvyr marks them retired.

The receiver must never trust X-Tenvyr-Key-Id by itself. Accept it only when it selects a key already pinned through the authenticated console/API response.

The receiver contract currently reports:

signature version:   tenvyr-webhook-signature-v1
signature algorithm: ECDSA_SHA_256

Create the destination

In Integrations → SIEM audit webhooks:

1. enter a display name;
2. enter the exact receiver URL;
3. complete recent MFA;
4. create the destination; and
5. queue a signed test marker.

Confirm the marker arrives and passes every validation below before treating the integration as healthy.

Tenvyr permits at most eight enabled destinations and retains at most 256 destination records per tenant.

Verify a delivery

For every request:

1. reject an unknown key ID or signature algorithm;
2. base64url-decode X-Tenvyr-Signature-Input;
3. reconstruct the canonical UTF-8 input from the received headers;
4. compare the reconstructed value with the decoded signature input;
5. SHA-256 hash the exact canonical input;
6. base64url-decode X-Tenvyr-Signature;
7. verify the ASN.1 DER ECDSA signature using the pinned P-256 key;
8. SHA-256 hash the exact received body and compare it with X-Tenvyr-Content-Sha256;
9. validate CloudEvents type, source, subject, time, destination, and tenant expectations; and
10. deduplicate on Idempotency-Key / Ce-Id.

Security-relevant headers covered by the signature include:

Ce-Specversion
Ce-Type
Ce-Source
Ce-Id
Ce-Subject
Ce-Time
Ce-Datacontenttype
Content-Type
Idempotency-Key
X-Tenvyr-Destination-Id
X-Tenvyr-Content-Sha256
X-Tenvyr-Key-Id
X-Tenvyr-Signature-Algorithm

Do not normalize, reorder, or rebuild the signing input with locale-sensitive logic. Implement the exact canonical contract supplied with the receiver integration.

Replace or disable a destination

Replacing a destination affects future reservations. Already reserved deliveries retain their immutable prior destination snapshot.

Disabling is a soft transition: delivery stops, while configuration and historical evidence remain available.

Delivery failures

A receiver failure cannot block Tenvyr's immutable S3 export or daily signed root. Failed webhook deliveries retry within their bounded policy and then appear in the tenant recovery queue.

Before replaying a dead letter:

1. correct the receiver dependency;
2. identify the immutable payload digest and destination;
3. attach a reason and evidence reference; and
4. replay the exact work item.

Replay cannot alter the tenant, destination, body, key, or idempotency identity.