Configuração dinâmica por chamada
Escolha o agente que atende — ou reescreva seu prompt e suas configurações — separadamente para cada chamada recebida, com base em lógica personalizada em um webhook que você controla.
Por padrão, cada número de telefone e chave publicável tem um agente estático atribuído. Quando precisar de personalização por quem liga ou por visitante — roteamento VIP, contexto de usuário autenticado, testes A/B de prompt — mude para o modo webhook e deixe seu servidor decidir.
Como funciona
- Assine o evento
telephony.incoming(telefone) ouweb.incoming(widget). Ambos são webhooks bloqueantes: o ThunderPhone espera até 10 segundos pela sua resposta antes de continuar a chamada. - O ThunderPhone envia
{call_id, from_number, to_number}para você (sessões de widget incluem campos específicos do widget em vez de números — consulte o esquema da solicitação). - Seu servidor responde com uma configuração de agente (prompt, voz, produto, ferramentas). O ThunderPhone usa essa configuração na chamada.
- Se você retornar
{}, exceder o tempo limite ou ocorrer um erro, o agente atribuído estaticamente será usado como alternativa. Padrão seguro.
1. Configure o destino do webhook
Para números de telefone, assine seu endpoint em telephony.incoming:
curl -X POST https://api.thunderphone.com/v1/developer/webhook-endpoints \
-H "Authorization: Bearer sk_live_YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"label": "Prod call-incoming",
"url": "https://example.com/thunderphone/incoming",
"events": ["telephony.incoming"]
}'A resposta inclui um secret de uso único — salve-o; você o usará
para verificação de assinatura.
Para sessões de widget, crie uma chave publicável em mode="webhook"
com a URL do seu endpoint incorporada:
curl -X POST https://api.thunderphone.com/v1/publishable-key \
-H "Authorization: Bearer sk_live_YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Dynamic widget",
"mode": "webhook",
"webhook_url": "https://example.com/thunderphone/widget-incoming",
"allowed_domains": ["example.com"]
}'O widget fará uma solicitação POST para esta URL no início de cada sessão.
2. Implemente o handler
Três regras práticas:
- Verifique a assinatura em cada solicitação (consulte Verificar assinaturas de webhook). Não pule isso no desenvolvimento — faça corretamente uma vez e reutilize.
- Responda rápido. Dez segundos é o limite máximo, e cada segundo é silêncio para quem liga. Faça consultas ao banco de dados se precisar, mas não chame LLMs downstream de forma síncrona — se quiser geração dinâmica de prompt, pré-calcule e armazene em cache.
- Use um fallback limpo. Qualquer estado inesperado deve retornar
{}para que o agente atribuído estaticamente atenda à chamada.
import hashlib
import hmac
import json
import os
from fastapi import FastAPI, HTTPException, Request
app = FastAPI()
SECRET = os.environ["THUNDERPHONE_WEBHOOK_SECRET"]
def verify(body: bytes, sig: str) -> bool:
expected = hmac.new(SECRET.encode(), body, hashlib.sha256).hexdigest()
return hmac.compare_digest(expected, sig or "")
@app.post("/thunderphone/incoming")
async def incoming(request: Request):
body = await request.body()
if not verify(body, request.headers.get("X-ThunderPhone-Signature", "")):
raise HTTPException(401)
event = json.loads(body)
if event["type"] not in ("telephony.incoming", "web.incoming"):
return {} # fall back to default
caller = event["data"]["from_number"]
# Cheap DB lookup: is this a known VIP?
customer = lookup_customer(caller)
if customer and customer.tier == "vip":
return {
"prompt": f"You are a VIP concierge for {customer.name}. Be proactive…",
"voice": "john",
"product": "storm-base",
}
return {} # default agent handles non-VIPs
def lookup_customer(phone: str):
# ... your CRM integration ...
passimport crypto from "node:crypto";
import express from "express";
const app = express();
const SECRET = process.env.THUNDERPHONE_WEBHOOK_SECRET;
function verify(body, sig) {
const expected = crypto.createHmac("sha256", SECRET).update(body).digest("hex");
return sig &&
crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(sig));
}
app.post(
"/thunderphone/incoming",
express.raw({ type: "application/json" }),
async (req, res) => {
if (!verify(req.body, req.header("X-ThunderPhone-Signature"))) {
return res.sendStatus(401);
}
const event = JSON.parse(req.body.toString("utf8"));
const IMPORTANT_TYPES = new Set([
"telephony.incoming",
"web.incoming",
]);
if (!IMPORTANT_TYPES.has(event.type)) return res.json({});
const customer = await lookupCustomer(event.data.from_number);
if (customer?.tier === "vip") {
return res.json({
prompt: `You are a VIP concierge for ${customer.name}. Be proactive…`,
voice: "john",
product: "storm-base",
});
}
res.json({}); // fall back to default agent
},
);3. Esquema de resposta
O corpo da resposta corresponde exatamente ao esquema de resposta de chamada recebida. Os campos usados com mais frequência:
| Campo | Tipo | Descrição |
|---|---|---|
prompt | string (obrigatório) | Prompt de sistema para o agente |
voice | string (obrigatório) | ID de voz de GET /v1/voices |
product | string | O padrão é spark |
background_track | string | null | ID de áudio ambiente |
acknowledgement_prompt_mode | string | auto ou manual (somente Storm com confirmação) |
acknowledgement_prompt | string | Obrigatório quando o modo é manual |
tools | array | Esquemas de ferramentas de função inline — consulte Ferramentas de função |
Padrões
Contexto de usuário autenticado
Em widgets no modo webhook, a página de quem visita já sabe quem essa pessoa
é. Chame seu webhook com um parâmetro de string de consulta que o SDK do widget
encaminha (?customer_id=123) e busque o cliente no lado do servidor.
Lançamento A/B de prompt
Antes de implementar isso manualmente, observe que o ThunderPhone tem um recurso nativo de
Experimentos
(/dashboard/experiments e a aba A/B do construtor de agentes) que
define variantes, divide o tráfego e compara os resultados por variante —
sem necessidade de webhook.
Se ainda precisar de controle no lado do webhook: aplique hash em call_id → bucket;
forneça o prompt A para 0..49 e o prompt B para 50..99. Registre qual
bucket você escolheu no seu próprio banco de dados e depois correlacione com a
avaliação da chamada concluída.
Roteamento baseado em horário
Horário comercial → agente de "suporte ao vivo"; fora do horário comercial → agente de "anotar uma mensagem".
Alternância simples com base em new Date().getUTCHours() no seu manipulador.
Próximas etapas
Esquemas exatos de solicitação e resposta, incluindo todas as chaves de configuração.
Configure o HMAC corretamente uma vez; reutilize em todos os lugares.
Combine roteamento dinâmico com ferramentas por agente.
Tentativas, ordenação, tempos limite.