Skip to main content

Eventos disponíveis

invoice.contingency está documentado na descrição do endpoint POST /v1/webhooks e na seção de Contingência da referência da API, mas não aparece na lista de valores aceitos do campo event de WebhookEditingDto no schema OpenAPI (que lista apenas invoice.status_changed, invoice.authorized, invoice.rejected e invoice.canceled). Há uma divergência entre a prosa e o schema — confirme com o time da Spedy se invoice.contingency já pode ser assinado como evento próprio antes de depender dele. Enquanto isso, invoice.status_changed cobre a transição para inContingent também.
Cada webhook assina um único evento (campo event em WebhookEditingDto, veja Gerenciamento de webhooks). Para receber mais de um tipo, crie um webhook por evento. Na maioria dos casos, assinar apenas invoice.status_changed é suficiente — ele cobre todo o ciclo de vida da nota (veja Ciclo de vida da nota), incluindo as mesmas transições que os eventos mais específicos (invoice.authorized, invoice.rejected, invoice.canceled) também disparam. Use os eventos específicos apenas se sua integração precisa reagir de forma diferenciada a cada um sem inspecionar o data.status do payload.

Envelope do payload

Todo evento é entregue como um HTTP POST com o corpo no seguinte formato:

Exemplo de payload

O exemplo abaixo é de uma autorização de NFS-e. O data contém os mesmos campos retornados por GET /v1/service-invoices/{id} — a estrutura é idêntica para NF-e e NFC-e, usando os campos dos respectivos endpoints de leitura.
Use data.company para identificar a empresa que gerou o evento (lembre-se: o webhook é por conta e recebe eventos de todas as empresas — veja Webhooks: visão geral) e data.status para saber o estado atual da nota (veja Ciclo de vida da nota para o significado de cada valor).