Struktura POST (przykład uproszczony)

{
  "request": {
    "FromNumber": "48123456789",
    "ToNumber": "48221234567",
    "ChannelStatus": "Connected",
    "UniqueCallId": "…",
    "Hash": "…",
    "Event": { "EventName": "Connected", "EventData": "" },
    "Session": null
  }
}

W praktyce to właśnie UniqueCallId + Event.EventName są kluczem do debugowania i korelacji z CRM/helpdeskiem.

Pola w request

• FromNumber – numer dzwoniącego.
• ToNumber – numer docelowy (często przydatny do call trackingu / rozdzielania numerów kampanii).
• ChannelStatus – status kanału/połączenia (kontekst stanu rozmowy).
• UniqueCallId – unikalny identyfikator rozmowy (korelacja logów, CRM, ticketów).
• Hash – wartość weryfikacyjna (jeśli skonfigurowana po stronie panelu).
• Event – zdarzenie: EventName + EventData.
• Session – stan zwrócony wcześniej przez Twoją aplikację (np. krok flow, licznik prób, ID sprawy).

EventName i EventData

Najczęściej spotykane zdarzenia:

• Connected – start scenariusza IVR API (dobry moment na pierwszy krok logiki).
• GetDTMF – wynik DTMF w EventData albo wartość typu timeout.
• CallStatus – wynik próby połączenia (np. Answer/Busy/Noanswer/Cancel/Error) w EventData.
• Play – informacja o zakończeniu zapowiedzi (jeśli dany flow opiera się o kolejne kroki po odtworzeniu).

Jeśli chcesz szybko skleić flow w jedną całość: Szybki start.

Error

Gdy wystąpi błąd wywołania aplikacji lub problem z wykonaniem akcji, request może zawierać obiekt Error (np. ErrorNo + ErrorMsg). To jest sygnał, że platforma weszła w ścieżkę awaryjną (fallback) albo że odpowiedź aplikacji była niepoprawna.

Jak to stabilizować w produkcji: Stabilność oraz Bezpieczeństwo webhooka.

Minimum diagnostyczne, które realnie ratuje czas: loguj UniqueCallId, EventName, czas odpowiedzi, oraz to, jaką Action zwróciła Twoja aplikacja.