Skip to main content
Som standard har hvert telefonnummer og hver offentlig nøgle en statisk agent tilknyttet. Når du har brug for tilpasning pr. opkalder eller pr. besøgende — VIP-routing, kontekst for indloggede brugere, A/B-tests af prompts — skal du skifte til webhooktilstand og lade din server afgøre det.

Sådan fungerer det

  1. Du abonnerer på hændelsen telephony.incoming (telefon) eller web.incoming (widget). Begge er blokerende webhooks: ThunderPhone venter op til 10 sekunder på dit svar, før opkaldet fortsætter.
  2. ThunderPhone sender dig {call_id, from_number, to_number} (widget- sessioner indeholder widgetspecifikke felter i stedet for numre — se anmodningsskemaet).
  3. Din server svarer med en agentkonfiguration (prompt, stemme, produkt, værktøjer). ThunderPhone bruger den konfiguration til opkaldet.
  4. Hvis du returnerer {}, får timeout eller en fejl, bruges den statisk tilknyttede agent som fallback. Sikker standard.
Fungerer identisk for telefonopkald (telephony.incoming) og widget- sessioner (web.incoming), uanset om de leveres til et webhook-endpoint eller til den ældre webhook med én URL.

1. Konfigurer webhookdestinationen

For telefonnumre skal du abonnere dit endpoint på telephony.incoming:
Svaret indeholder en secret til engangsbrug — gem den; du skal bruge den til signaturverificering.

2. Implementer håndteringsfunktionen

Tre tommelfingerregler:
  • Bekræft signaturen for hver anmodning (se Bekræft webhook-signaturer). Spring ikke dette over i udvikling — gør det rigtigt én gang, og genbrug det.
  • Svar hurtigt. Ti sekunder er den hårde grænse, og hvert sekund er stilhed for den, der ringer. Udfør databaseopslag, hvis du har brug for det, men kald ikke efterfølgende LLM’er synkront — hvis du vil have dynamisk promptgenerering, skal du forudberegne og cache.
  • Fald rent tilbage. Enhver uventet tilstand skal returnere {}, så den statisk tildelte agent håndterer opkaldet.

3. Svarskema

Svarbrødteksten matcher svarskemaet for indgående opkald præcist. De mest anvendte felter:
Talerækkefølge pr. opkald og max_hold_seconds er ikke tilgængelige i webhook-svaret. Indstil dem på den agent, du refererer til.

Mønstre

Kontekst for logget ind-bruger

I widgets i webhook-tilstand ved den besøgendes side allerede, hvem vedkommende er. Kald din webhook med en query string-parameter, som widget-SDK’et videresender (?customer_id=123), og slå kunden op på serversiden.

A/B-udrulning af prompts

Før du bygger dette selv, skal du bemærke, at ThunderPhone har en indbygget Experiments-funktion (/dashboard/experiments og agentbyggerens A/B-fane), som definerer varianter, fordeler trafik og sammenligner resultater pr. variant — ingen webhook nødvendig. Hvis du alligevel har brug for kontrol på webhook-siden: hash call_id → bucket; servér prompt A for 0..49 og prompt B for 50..99. Registrer, hvilken bucket du valgte, i din egen database, og korreler senere med det afsluttede opkalds vurdering.

Tidsbaseret routing

Åbningstid → agent for “live-support”; uden for åbningstid → agent for “tag en besked”. Rent skift baseret på new Date().getUTCHours() i din handler.

Næste trin

Webhook-reference for indgående opkald

Præcise request- og response-skemaer, inklusive alle konfigurationsnøgler.

Bekræft webhook-signaturer

Få HMAC rigtigt én gang, og genbrug det overalt.

Byg en værktøjsintegration

Kombiner dynamisk routing med værktøjer pr. agent.

Leveringssemantik

Genforsøg, rækkefølge, timeouts.