From webhook to push notification in one HTTP call

You already receive webhooks from GitHub, Supabase or your own backend. Forward the fields that matter to LogsNinja and the same payload becomes a native alert and a point on a chart.

Workflow failed#deploys ·

A webhook you already receive

Stripe, GitHub, Supabase and most SaaS tools already push a JSON payload to an endpoint you control the moment something happens. That payload usually ends up logged, or silently ignored until something breaks. The fields you need for an alert are already in it – you just have to forward them.

Three steps inside the handler you already have

Verify the signature
Map the fields
Send the event
FROM WEBHOOK TO EVENT

A GitHub Actions payload, forwarded as an event

Verify the signature, pull the conclusion and repository name out of the payload, then send one HTTP call – the same idea applies to Supabase, Stripe or your own backend.

$ curl -X POST https://api.logsninja.com/v1/events \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -d '{
    "project": "YOUR_PROJECT_ID",
    "stream":  "deploys",
    "title":   "Workflow failed",
    "content": "deploy.yml on main",
    "emoji":    "🚨",
    "metadata": {"repo": "org/app"},
    "notify":   true
  }'

✓ Event received
✓ Push sent to 2 devices
# feed and chart updated

Popular webhook sources

Stripe

Payments, invoices and subscription changes.

GitHub

Deployments, pull requests and workflow failures.

Supabase

Database changes and auth events.

Your own backend

Any internal event you already emit as a webhook.

Ship it safely

Verify before you trust

  • Check the provider's signature header before processing anything – GitHub, Stripe and Supabase each sign their payloads.
  • Keep your webhook signing secret and your LogsNinja API token out of client-side code.
  • Only forward the fields you actually need for the alert or the chart, not the full payload.

Handle retries

  • Most providers retry undelivered webhooks – return 200 quickly and process asynchronously if needed.
  • Use the provider's delivery ID as an idempotency key so a retried webhook does not create a duplicate alert.
  • Set notify to false for high-volume events you only want on a chart, not as a push.

Build these on your dashboard

Every widget below reads the same events you just started sending – no second integration.

14
Deployments todayUpdated
1
Failed workflowsUpdated
3
Database migrationsUpdated

Example values shown for illustration.

Frequently asked questions

Do I need a new endpoint for this?

No. Add one HTTP call to LogsNinja inside the handler that already receives the webhook, after you verify its signature.

Does this work for webhooks other than GitHub?

Yes. The same three steps – verify, map the fields, send the event – apply to Stripe, Supabase or any provider that sends a signed JSON payload.

What if I only want some webhook events to alert, not all of them?

Set notify to false for the ones you only want on a chart, and true for the ones that deserve a push – both read the same payload.

Turn your next webhook into an alert.

See the full webhook notifications feature and connect your first provider.