Skip to main content
Cada mudança relevante gera um evento: um fato imutável sobre um recurso. Webhooks, o painel e a contabilização de uso leem desse mesmo log. Você consome eventos de duas formas:
  • Webhooks: a Routa envia cada evento ao seu endpoint HTTPS. Veja Webhooks.
  • Consulta: GET /v1/events lista eventos e é o caminho de reconciliação se você perdeu entregas.

O objeto evento

Como data traz o recurso completo, um consumidor que processa apenas o último evento de cada recurso converge para o estado correto.

Tipos de evento

Veja os detalhes de cada tipo em Tipos de evento.
Novos tipos de evento podem surgir a qualquer momento. Por isso, cada endpoint de webhook assina uma lista explícita de tipos (por exemplo message.delivered) ou um curinga por recurso (message.*). Ignore tipos que seu código não reconhece.

Semântica de entrega

A entrega é pelo menos uma vez (at-least-once), sem garantia de ordem global. Seu consumidor precisa:
1

Deduplicar por id

Guarde os id de eventos já processados (um conjunto com TTL de 24 horas costuma bastar) e ignore repetidos.
2

Ignorar o desconhecido

Ignore tipos de evento e campos que você não reconhece.
3

Tratar o status como monotônico

Nunca rebaixe uma mensagem de read para sent só porque um evento mais antigo chegou depois. Compare o status ou use occurred_at.
O SDK oficial já ajuda com isso: eventos de tipos desconhecidos são interpretados como um evento genérico em vez de causar erro. Veja Webhooks no SDK.

Consultar eventos perdidos

Se seu servidor ficou fora do ar, não é preciso pedir reenvio ao suporte. Liste os eventos a partir do último que você processou:
O cursor é o próprio id do evento (after). A resposta traz has_more e next_cursor. Veja GET /v1/events e Reconciliar eventos.

Retenção

Os eventos ficam disponíveis por 90 dias.