Skip to main content

Webhooks das linhas telefônicas

As linhas telefônicas enviam seus eventos para os webhooks das linhas: um cadastro próprio, separado dos webhooks de número. Os dois nunca se misturam:
  • Um webhook de número — mesmo um inscrito em "*" — nunca recebe um evento phone_line.*.
  • Um webhook de linha recebe apenas eventos phone_line.*, nunca eventos de mensagem ou de número.

Configurar (somente pelo painel)

Não há API pública para webhooks de linha. Gerencie-os no painel em Linhas → Webhooks das linhas (/linhas/webhooks), como Proprietário ou Administrador:
  • URL de destino — precisa ser https.
  • Eventos — escolha um ou mais dos eventos abaixo, ou todos ("*"). Neste cadastro, "*" significa todos os eventos de linha. É obrigatório escolher pelo menos um.
  • Segredo de assinatura — exibido uma única vez, quando o webhook é criado (começa com plwh_). Guarde-o imediatamente: nada o exibe de novo, e não há rotação. Para trocá-lo, crie um novo webhook, passe seu receptor a usar o segredo dele e exclua o antigo.
  • Pausar / retomar e excluir. O painel não edita a URL nem os eventos de um webhook: crie um novo webhook e exclua o antigo.
  • Log de entregas — por webhook: evento, status (pendente, entregue, com falha), tentativas, o status HTTP que seu endpoint respondeu e o último erro.
Um workspace pode ter mais de um webhook de linha; cada um recebe os eventos em que se inscreveu.

Eventos

phone_line.code_received é disparado somente quando uma transcrição é concluída. Um pedido que termina em TIMED_OUT, FAILED ou CAPTURED com falha na transcrição não envia evento algum — se você aguarda o webhook, acompanhe também o pollDeadline do pedido ou consulte GET /v1/phone-lines/activations/{activationId}.

Formato do payload

Toda entrega é um POST com corpo JSON:
Cabeçalhos:
Aqui os números não têm +. number traz os dígitos E.164 sem o sinal de mais (551148637200), exatamente como nos endpoints /v1/phone-lines — ao contrário dos webhooks de número, cujos campos de telefone trazem +.

Payloads

lineId é o id da linha em GET /v1/phone-lines/{id}.
code é null quando a ligação foi transcrita, mas nenhum código de 6 dígitos foi encontrado nela (nesse caso, o failureReason do pedido é no_code_in_transcript). A gravação pode ser ouvida no painel.
Este payload traz o código de ativação, que é uma credencial. Verifique a assinatura antes de confiar nele e não registre o corpo em log.
currentPeriodEnd é o fim do período que acabou de ser pago.
status é um destes valores:Não há endpoint público para ler a verificação; o verificationId a identifica nas conversas com o suporte.

Verificar a assinatura

Todo webhook de linha tem um segredo, então toda entrega é assinada. x-pilot-status-signature é o HMAC-SHA256 do corpo bruto da requisição, codificado em hexadecimal, usando o segredo do webhook como chave (a string inteira, incluindo o prefixo plwh_). Calcule-o sobre os bytes exatamente como foram recebidos — antes de qualquer parse do JSON — e compare em tempo constante:
É o mesmo cálculo usado nos webhooks de número, então um receptor que já verifica esses webhooks funciona aqui com o segredo deste webhook. A assinatura cobre apenas o corpo — não há cabeçalho de timestamp —, então use o id para descartar duplicatas.

Entrega e retentativas

  • Responda com qualquer 2xx em até 10 segundos. Qualquer outra coisa — outro status, um timeout, um erro de conexão — conta como tentativa com falha.
  • 6 tentativas no total: a primeira imediatamente, depois novas tentativas com intervalos de cerca de 30 s, 1 min, 2 min, 4 min e 8 min — normalmente cerca de 15 minutos do início ao fim. Depois da última, a entrega é marcada como falha no log. Uma entrega que não pôde ser enfileirada de início é retomada por uma varredura horária, então a primeira tentativa dela pode vir mais tarde.
  • Redirecionamentos não são seguidos. Uma resposta 3xx conta como tentativa com falha.
  • Pelo menos uma vez. Se o seu endpoint processou o evento, mas não respondeu a tempo, a retentativa o entrega de novo, com o mesmo id. A ordem não é garantida.
  • Webhooks pausados ou excluídos. Um evento é entregue somente aos webhooks que estão ativos e inscritos no momento em que ele acontece. Cada tentativa confere o webhook de novo: uma entrega cujo webhook está pausado quando uma tentativa chega — inclusive uma que já está nas retentativas — é marcada como falha e não é enviada depois; excluir um webhook descarta as entregas pendentes dele. Os eventos nunca são reenviados a um webhook criado ou retomado depois.
  • Destinos internos são recusados. Uma URL cujo host resolve para um endereço de rede privada ou interna não é chamada, nem recebe novas tentativas. Uma URL assim é aceita na criação do webhook — nesse momento só o https e os nomes dos eventos são conferidos —, então toda entrega para ela fica registrada como falha. Já uma consulta DNS que falha é diferente: recebe novas tentativas como qualquer outra falha.
Trate esses eventos como notificações, não como a fonte da verdade. Quando algum puder ter se perdido — seu endpoint ficou fora do ar por mais tempo do que duram as retentativas —, leia o estado atual com GET /v1/phone-lines.