Sazabi
Log sourcesSend to an endpoint

Webhook Events

Point any vendor's webhooks at your Sazabi intake URL to store arbitrary JSON events as searchable log records with no schema or field mapping required.

About

Point any vendor's webhook delivery at your Sazabi intake URL and each JSON payload lands as a searchable log record. No schema, field mapping, or vendor-specific configuration is required — the entire payload is preserved under webhook.* attributes and is immediately queryable.

A single JSON object becomes one event. A JSON array becomes one event per element. Sazabi reads common field names to extract timestamp and severity when present.

The intake URL itself is the credential: the URL encodes your project public key in the hostname, so treat it as a secret.

Prerequisites

  • A vendor or service that can send webhooks as JSON.
  • Your Sazabi intake URL (shown above).

Only JSON payloads are accepted. Form-encoded, XML, and other content types are not supported.

Set up in the dashboard

Note your intake URL and path options

Your intake URL is shown above. You can append an arbitrary path suffix to organize events by type — for example, /deploys or /alerts. The path is stored as the webhook.path attribute on each event:

# Single event
curl -X POST <your intake URL>/deploys \
  -H 'content-type: application/json' \
  -d '{"event":"deploy.completed","service":"api","sha":"abc123"}'

# Array of events — each element becomes a separate record
curl -X POST <your intake URL>/alerts \
  -H 'content-type: application/json' \
  -d '[{"alert":"cpu_high","host":"web-1"},{"alert":"cpu_high","host":"web-2"}]'

Configure the vendor

Paste your intake URL into the vendor's webhook settings. When the vendor asks for a format, choose JSON. Most vendors also let you configure which events to deliver — select only the event types you want to store.

No authentication headers or API keys are required from the vendor side — the intake URL encodes your project's public key.

Set up with the CLI

You can also register the Webhook Events log source with the Sazabi CLI (installed and authenticated — see CLI reference).

Registering the source mints the same intake URL the dashboard shows above (the public key is embedded in its hostname):

sazabi log-sources create webhook_events --mode connectionless

The command prints the intake URL for the new source — copy the whole URL and point your sender at it using the configuration shown above. Run sazabi log-sources get <log-source-id> at any time to reprint the endpoint, or sazabi log-sources list to see every log source in the project.

Verify

Send a test event using the curl example above, or trigger a test webhook delivery from the vendor's dashboard. Open the Intake page in the Sazabi dashboard and confirm the event appears in the Webhook Events source within a minute or two.

Start a thread in the dashboard and search for a field from your payload — for example, webhook.event — to confirm the full payload is queryable.

Troubleshooting

Events not appearing — Confirm the vendor is sending Content-Type: application/json and the body is valid JSON. Non-JSON content types are rejected at intake.

Only some events arriving — If the vendor sends arrays, each element becomes a separate record. If the vendor wraps multiple events in a nested object rather than an array, the entire object is stored as one record.

Path not recorded — Only the path segment appended after your intake URL is stored as webhook.path. The intake hostname and key segment are not included in the stored path.

Intake URL treated as expired — The intake URL encodes your project public key. If you rotate or delete the public key in Settings > Public keys, the URL stops accepting events. Generate a new intake URL from the log source setup flow.

Further reading