Webhook: odpowiedź (Action + Session)
Odpowiadasz JSON-em. Minimalnie zwracasz Action (czyli co platforma ma zrobić teraz). Opcjonalnie zwracasz Session — stan rozmowy, który wróci do Ciebie w kolejnym webhooku.
Minimalny przykład
{
"Action": { "Type": "Play", "Prompt": "1" },
"Session": { "step": "welcome" }
}
Prompt to identyfikator zapowiedzi ustawionej w panelu IVR API.
Najprostszy test: Connected → Play → Hangup.
Action: jedna akcja na krok
Model jest „event-driven”: platforma wywołuje webhook, Ty zwracasz jedną decyzję, platforma wykonuje akcję, a potem (jeśli trzeba) przychodzi kolejne zdarzenie. Dzięki temu logika jest przewidywalna i łatwa do debugowania.
- Play → w kolejnym webhooku zobaczysz zdarzenie związane z odtworzeniem.
- GetDTMF → w kolejnym webhooku dostaniesz wynik (cyfry albo timeout).
- Call… → w kolejnym webhooku dostaniesz CallStatus (Answer/Busy/Noanswer/Cancel/Error).
Pełna lista typów i parametrów: Akcje API (referencja).
Session: prosty state machine
Session wraca do Ciebie w następnym request i pozwala prowadzić rozmowę w krokach (bez utrzymywania serwera „na sesji”).
- trzymaj krok rozmowy (np.
step), - licz próby DTMF (np.
tries), - przechowuj zebrane dane (np.
order_id,ticket_id), - trzymaj krótkie wartości — tak, żeby logi były czytelne.
Dobra praktyka: nie wkładaj do Session danych wrażliwych. Jeśli musisz przechować kontekst, przechowuj identyfikator i mapuj go u siebie (np. w cache/DB).
Gotowe wzorce (DTMF + retries + routing + fallback): Przykłady kodu.
Najczęstszy schemat produkcyjny
- Connected → Play (krótki komunikat)
- GetDTMF → identyfikator (zamówienie/ticket/kod)
- lookup w CRM/helpdesku
- Call… do opiekuna lub kolejki
- CallStatus → fallback (backup, eskalacja, komunikat)
Stabilność i fallbacki: Stabilność.
Gotowy na kolejny krok?
Jeśli masz już request, odpowiedź i Session, to teraz najczęściej wchodzą: GetDTMF, Call… i obsługa CallStatus.