Webhooki niestandardowe

Routuj webhook dowolnego serwisu na połączenia, Telegram i eskalację

Jeśli Twój serwis potrafi POST JSON, WardenPoint potrafi to eskalować. Wewnętrzne skrypty, GitHub Actions, schedulery, urządzenia IoT, narzędzia in-house — ten sam kontrakt, ten sam dziennik audytu.

Verb
POST JSON
Auth
X-API-Key
Cykl życia
UUID

Anatomia własnego alertu

LIVE
Twój serwis → POST
spike fraud, próg przekroczony
WardenPoint
waliduj · wzbogać · eskaluj
Telegram
Voice call
Email

Konfiguracja

Trzy linie curl

Brak UI integracji do nauki. Wydaj klucz API, ustaw nagłówek, wyślij JSON. Cokolwiek od cron-a bash po serwis Go używa tego samego kontraktu.

  1. 1Krok 1

    Wydaj klucz API

    Dashboard → Settings → API Keys → Create. Zwęź klucz per integracja, żeby rewokacja była celowana.

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

    Wybierz UUID odbiorcy

    Wybierz odbiorcę lub grupę z dashboardu. UUID to Twój cel routingu.

    $ Recipients › copy UUID
  3. 3Krok 3

    POST alert

    Wyślij POST /api/v1/notifications/send z X-API-Key, recipient_uuid, message i priority. To pełny kontrakt.

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

Format na drucie

Kontrakt niestandardowego webhooka

Cztery wymagane pola, jedna opcjonalna etykieta source. Cokolwiek wyślesz, pojawia się w dzienniku audytu z tym samym kształtem jak każda inna integracja.

Twój serwis → 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"
}'
Rozsyłka WardenPoint
WardenPoint response202
{
"status": "queued",
"notification_uuid": "notif_8h2k7yQrxJp",
"channels_planned": [
"telegram_voice",
"voice_call",
"email"
],
"escalation_chain_id": "esc_4j2k9bMcvL"
}

Wzorce routingu

Trzy patterny, które widzimy z własnych źródeł

Zadania cron, moduły CI oraz usługi wewnętrzne mają te same trzy wymagania.

Cron

Cron + curl

Bash cron sprawdza wewnętrzny endpoint i POSTuje do WardenPoint, gdy się sypie. Pięć linii bash, zero zależności.

match
exit_code != 0
→ route
priority: critical
CI

GitHub Actions on failure

Dodaj Step z if: failure(), który POSTuje alert do WardenPoint. Tylko padające pipeline'y budzą dyżurnego.

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

Alerty serwisów in-house

Wbuduj wywołanie w swój serwis. Każda własna anomalia (fraud, lag kolejki, próg balansu) może stać się incydentem WardenPoint.

match
anomaly: fraud_spike
→ route
group: fraud_oncall

FAQ Webhooks

Najczęstsze pytania o custom-webhook

Tak. Skonfiguruj je w Dashboard → Integracje → Webhooki. Subskrybuj zdarzenia cyklu życia alertu (sent / delivered / acknowledged / escalation.* / contact failed). Każde żądanie jest podpisane HMAC-SHA256 w nagłówku X-WardenPoint-Signature; weryfikuj podpis po swojej stronie.
Plan darmowy

Wyślij pierwszy własny alert w dwie minuty

Wydaj klucz API, skopiuj snippet curl, podmień UUID odbiorcy i odpal. Dziennik audytu zapala się natychmiast.

  • Plan darmowy
  • Kontrakt trzech pól
  • Idempotency wbudowane