Custom webhooks

Route any service's webhook to phone calls, Telegram and escalation

If your service can POST JSON, WardenPoint can escalate it. Internal scripts, GitHub Actions, schedulers, IoT devices, in-house tools — same contract, same audit trail.

Verb
POST JSON
Auth
X-API-Key
Lifecycle
UUID

Anatomy of a custom alert

LIVE
Your service → POST
fraud spike, threshold breached
WardenPoint
validate · enrich · escalate
Telegram
Voice call
Email

Setup

Three lines of curl

No integration UI to learn. Issue an API key, set a header, post the JSON. Anything from a bash cron to a Go service uses the same contract.

  1. 1Step 1

    Issue an API key

    Dashboard → Settings → API Keys → Create. Scope the key per integration so revoking is targeted.

    $ Settings › API Keys › Create
  2. 2Step 2

    Choose a recipient UUID

    Pick a recipient or recipient group UUID from the dashboard. The UUID is your routing target.

    $ Recipients › copy UUID
  3. 3Step 3

    POST the alert

    Send POST /api/v1/notifications/send with X-API-Key, recipient_uuid, message and priority. That is the full contract.

    $ curl -X POST .../notifications/send

Wire format

The custom-webhook contract

Four required fields, one optional source label. Whatever you send appears in the audit log with the same shape as every other integration.

Your service → WardenPoint
send-alert.shBASH
curl -X POST https://api.wardenpoint.com/api/v1/notifications/send \
-H "X-API-Key: $WARDENPOINT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"recipient_uuid": "00000000-0000-4000-8000-000000000001",
"message": "Custom service alert",
"priority": "critical",
"source": "custom"
}'
WardenPoint fan-out
WardenPoint response202
{
"status": "queued",
"notification_uuid": "notif_8h2k7yQrxJp",
"channels_planned": [
"telegram_voice",
"voice_call",
"email"
],
"escalation_chain_id": "esc_4j2k9bMcvL"
}

Routing recipes

Three patterns we see from custom sources

Cron jobs, CI runners and internal services all share the same three needs.

Cron

Cron + curl

A bash cron checks an internal endpoint and POSTs to WardenPoint when it fails. Five lines of bash, zero dependencies.

match
exit_code != 0
→ route
priority: critical
CI

GitHub Actions on failure

Add a Step with if: failure() that posts a WardenPoint alert. Only failing pipelines page on-call.

match
if: failure()
→ route
group: ci_oncall
Service

In-house service alerts

Embed the call inside your service. Any custom anomaly (fraud, queue lag, balance threshold) can become a WardenPoint incident.

match
anomaly: fraud_spike
→ route
group: fraud_oncall

Webhooks FAQ

Common custom-webhook questions

Yes. Configure them in Dashboard → Integrations → Webhooks. Subscribe to notification lifecycle events (sent / delivered / acknowledged / escalation.* / contact failed). Each request is signed with HMAC-SHA256 in the X-WardenPoint-Signature header; verify the signature on your side.
Free plan

Send your first custom alert in two minutes

Issue an API key, copy the curl snippet, swap your recipient UUID and run it. The audit log lights up immediately.

  • Free forever plan
  • Three-field contract
  • Idempotency built in