Webhook Events to Logs

Last verified on Nov 8, 2026.

Most SaaS products can send a webhook, and few of them have a log source of their own. The Webhook Events source covers that gap. You paste one URL into the vendor's webhook settings and each delivery becomes a searchable record, with no parser to write.

What the source does

Sazabi keeps the entire JSON payload under webhook.* attributes. A single JSON object becomes one event. A JSON array becomes one event per element, so a vendor that batches ten events in one delivery gives you ten records. Sazabi also reads common field names to extract a timestamp and severity when the payload has them.

Only JSON is accepted. The vendor has to send Content-Type: application/json with a valid body.

What it tells you

Webhooks are a vendor's own account of what happened: an order was paid, a deploy finished, a ticket changed state, an email bounced. Those events usually live in a vendor dashboard that nobody checks until something breaks. In Sazabi they sit beside your application logs and can be searched together.

That is the useful part. A payment webhook that says a charge succeeded and an application log that says the order failed to save are two halves of one story, and they only help when you can put them in one query.

Example: a deploy webhook and an alert batch

You can try the source without any vendor. This example posts one event to a path called /deploys and a two-element array to /alerts:

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

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"}]'

The first call produces one record with webhook.path set to /deploys. The second produces two records, one per host, with webhook.path set to /alerts. Search for webhook.event to find the deploy and filter on the path to separate the streams.

The path suffix is the cheapest organization you can add. Use one path per vendor or per event family, and later filters stay short.

Choosing paths and events

A path suffix costs nothing, so use it. A common layout is one path per vendor, such as /billing for payments and /support for tickets, with the event type left in the payload. That keeps queries like "all billing events in the last hour" to a single filter.

Be selective about event types. Many platforms let you subscribe to everything, and most of it is rarely read. Start with the events that mark a state change you would otherwise discover from a customer: payment failures, deploys, bounces, ticket escalations. You can widen the subscription later. A delivery with a single JSON object becomes one record, so subscription breadth is record volume.

Set it up

1. Get your intake URL from the Webhook Events source, or run sazabi log-sources create webhook_events --mode manual from the CLI.
2. Paste the URL into the vendor's webhook settings and choose JSON when it asks for a format.
3. Select only the event types you want to store.
4. Send a test delivery, then open the Intake page and confirm it appears in the Webhook Events source within a minute or two.

The vendor does not need to send any authentication header or key.

Treat the intake URL as a secret

The URL is the credential. It encodes your project public key in the hostname, so anyone who has it can send events. Keep it out of public repositories and shared screenshots. If you rotate or delete the public key in Settings, the URL stops accepting events, and you generate a new one from the log source setup flow.

Troubleshooting

• Nothing shows up. Check that the vendor sends application/json and the body parses as JSON.
• Fewer records than expected. Arrays are split. A nested wrapper object is not.
• No path recorded. Only the segment after the intake URL is stored as webhook.path. The hostname and key are left out.

Platform guides

Some platforms have their own page with the facts that matter for setup: Shopify, SendGrid, Jira, GitLab and HubSpot. Plain has a dedicated source, so see Plain for support events. For metrics and traces rather than events, use OpenTelemetry. Browse every source on the integrations page or check pricing before you plan volume.