Skip to content
Start free

Infrastructure

Events you can verify, and never sent to an internal address

A webhook sender is an SSRF primitive wearing a friendly name: you hand a service a URL and it fetches it. The guard against that is the load-bearing part of this feature, and it is checked twice on purpose.

Start freeSee all three layers

14-day evaluation · no card · start before you connect anything

How it works

  1. 1

    Every delivery is signed

    Each is signed with your endpoint’s secret over a timestamp and the raw body, so your receiver can reject anything forged or replayed rather than trusting that the request looks right.

  2. 2

    Secrets rotate with an overlap

    During rotation both secrets sign, so you can move to the new one without a window where deliveries fail verification.

  3. 3

    The address is checked when you save it, and again before every send

    Twice, because DNS can change in between. No webhook is ever sent to a private or internal address, and the check that matters is the last one taken.

  4. 4

    A failing endpoint is backed off, not hammered

    Delivery retries with backoff and breaks the circuit on an endpoint that keeps failing, so your outage does not become a flood when you recover.

DeliveryExample
POST https://your-app.example/hooks/xyranik
X-Xyranik-Signature: t=1758…,v1=9c4b…
Content-Type: application/json

{ "event": "decision.recorded", "id": "evt_…" }

  • Signature

    Over the timestamp and the raw body, so a forgery or a replay fails

  • Rotation

    Both secrets sign during the overlap, so nothing breaks mid-change

  • Address check

    Run when you save it and again before every send — DNS can change between

  • Circuit breaker

    A failing endpoint is backed off, not hammered

What you can build with it

  • Send yourself a test event

    You can trigger a test delivery to confirm your receiver answers correctly before relying on it.

  • Choose only the events you want

    Endpoints subscribe to specific events rather than receiving everything, and the full list with its payloads is in the developer reference.

  • Deliveries are recorded

    What was attempted, what answered and what failed is on record, so a missing event is a question with an answer.

Limits, and what is not served

Listed here rather than discovered against a rate limiter at three in the morning.

  • Delivery is at-least-once

    A delivery can arrive twice — for instance when your endpoint answered slowly. Your receiver needs to be idempotent, and we would rather say so than imply exactly-once semantics nobody can offer.

  • No replay from the interface

    Failed deliveries are recorded and retried automatically, but there is no button to replay an arbitrary past event on demand.

Build an agent that can act without a blank cheque

Your agents ask the same gateway ours do, on a credential of their own, and are held to the same permissions, limits and record. The endpoint list is served by the API itself rather than written out here.

Start freeSee what each plan includes

Read next