Власні webhooks

Маршрутизуйте webhook будь-якого сервісу у дзвінки, Telegram, ескалацію

Якщо ваш сервіс уміє POST JSON, WardenPoint уміє ескалувати. Внутрішні скрипти, GitHub Actions, шедулери, IoT-пристрої, in-house інструменти — той самий контракт, той самий журнал аудиту.

Почати безкоштовно Дивитися приклади API
Verb
POST JSON
Auth
X-API-Key
Lifecycle
UUID

Анатомія власного alert

LIVE
Ваш сервіс → POST
fraud spike, поріг перевищено
WardenPoint
валідація · збагачення · ескалація
Telegram
Voice call
Email

Налаштування

Три рядки curl

Жодного UI інтеграції. Видайте API-ключ, виставте заголовок, POST-ніть JSON. Усе — від bash-cron до Go-сервісу — використовує той самий контракт.

  1. 1Крок 1

    Видайте API-ключ

    Dashboard → Settings → API Keys → Create. Звузьте ключ per integration, щоб ревокація була точкова.

    $ Settings › API Keys › Create
  2. 2Крок 2

    Оберіть UUID одержувача

    Виберіть одержувача або групу з дашборду. UUID — ваша ціль маршрутизації.

    $ Recipients › copy UUID
  3. 3Крок 3

    POST alert

    Надішліть POST /api/v1/notifications/send з X-API-Key, recipient_uuid, message і priority. Повний контракт.

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

Формат у мережі

Контракт custom-webhook

Чотири обов'язкові поля, одна опціональна мітка source. Усе, що відправите, з'являється в журналі аудиту з тією ж формою, що й будь-яка інша інтеграція.

Ваш сервіс → 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
WardenPoint response202
{
"status": "queued",
"notification_uuid": "notif_8h2k7yQrxJp",
"channels_planned": [
"telegram_voice",
"voice_call",
"email"
],
"escalation_chain_id": "esc_4j2k9bMcvL"
}

Маршрутизація-рецепти

Три патерни з custom-джерел

Cron-jobs, CI runners і внутрішні сервіси мають ті ж три потреби.

Cron

Cron + curl

Bash-cron перевіряє внутрішній endpoint і POST-ить у WardenPoint при падінні. П'ять рядків bash, нуль залежностей.

match
exit_code != 0
→ route
priority: critical
CI

GitHub Actions on failure

Додайте Step з if: failure(), що POST-ить alert у WardenPoint. Лише невдалі pipelines будять чергового.

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

Alerts власних сервісів

Вмонтуйте виклик у свій сервіс. Будь-яка власна аномалія (fraud, лаг черги, поріг балансу) може стати WardenPoint-інцидентом.

match
anomaly: fraud_spike
→ route
group: fraud_oncall

FAQ Webhooks

Часті питання про custom-webhook

Так. Налаштуйте їх у Dashboard → Інтеграції → Вебхуки. Підпишіться на події життєвого циклу (sent / delivered / acknowledged / escalation.* / contact failed). Кожен запит підписаний HMAC-SHA256 у заголовку X-WardenPoint-Signature; перевіряйте підпис на своєму боці.
Безкоштовний план

Надішліть перший власний alert за дві хвилини

Видайте API-ключ, скопіюйте curl-snippet, замініть UUID одержувача і запустіть. Журнал аудиту спалахне миттєво.

Почати безкоштовно Назад до інтеграцій
  • Безкоштовний план
  • Контракт із трьох полів
  • Idempotency вбудовано