logo
logo
Docs Webhook Overview Webhook Request

O que o Webhook me envia?

O webhook envia um evento por requisição HTTP POST com Content-Type: application/json com os seguintes parâmetros:
  • um header X-IFood-Signature utilizado para verificar se a request veio do iFood

Assinatura da Request de Webhook

Página descrevendo como funciona a assinatura de uma request do webhook e como utilizá-lo para validar a request
Más información

Formato dos eventos

Página descrevendo o payload de um evento de pedido
Más información

Formato dos eventos de presença

Página descrevendo o payload de uma request de presença
Más información

Exemplos

Curl

Exemplo de curl assumindo SECRET: "dummysecret":
curl --location 'http://localhost:8080/webhook' \
--header 'X-IFood-Signature: 6f9ed23a7b505a3b6907c5f6eb2ad1b056fbf35a643d365a9a072ed7aabca153' \
--header 'Content-Type: application/json' \
--data '{"code":"PLC","createdAt":"2023-02-20T18:19:03.20162269Z","fullCode":"PLACED","id":"a38ba215-f949-4b2c-982a-0582a9d0c10e","merchantId":"cad65e8f-6fc6-438a-b159-e64a902a6b9a","orderId":"2c97e104-35ed-4c18-85d7-854a40b6b9e3"}'
Aproveito aqui para reforçar a questão de validar a assinatura do payload assim que ele chega (como byte array), sem nenhum tipo de parse da informação.
  • Exemplo de uma request com payload equivalente, apenas com alguns espaços extras que afetam a assinatura, mas igualmente válida:
curl --location 'http://localhost:8080/webhook' \
--header 'X-IFood-Signature: cf7e092c9148a48f5ee5f12b947f46b331eac6bf0745e1e1d0f3df722e219df3' \
--header 'Content-Type: application/json' \
--data '{ "code":"PLC", "createdAt":"2023-02-20T18:19:03.20162269Z", "fullCode":"PLACED", "id":"a38ba215-f949-4b2c-982a-0582a9d0c10e", "merchantId":"cad65e8f-6fc6-438a-b159-e64a902a6b9a", "orderId":"2c97e104-35ed-4c18-85d7-854a40b6b9e3" }'
  • Exemplo de outra request com payload equivalente, agora formatada para facilitar a leitura, o que também acarreta em outra assinatura igualmente válida:
curl --location 'http://localhost:8080/webhook' \
--header 'X-IFood-Signature: adf5446334f754e73588f3ae10b308306307f0c797f7f678912d740c6deddf6a' \
--header 'Content-Type: application/json' \
--data '{
    "code":"PLC",
    "createdAt":"2023-02-20T18:19:03.20162269Z",
    "fullCode":"PLACED",
    "id":"a38ba215-f949-4b2c-982a-0582a9d0c10e",
    "merchantId":"cad65e8f-6fc6-438a-b159-e64a902a6b9a",
    "orderId":"2c97e104-35ed-4c18-85d7-854a40b6b9e3"
}'
  • Exemplo de outra request com payload equivalente, mas com a ordem das propriedades trocadas, o que também acarreta em outra assinatura:
curl --location 'http://localhost:8080/webhook' \
--header 'X-IFood-Signature: e2d26f22f89932ff3d23a699031b22d6f30323501430dc08c3a971dd875e23b5' \
--header 'Content-Type: application/json' \
--data '{"merchantId":"cad65e8f-6fc6-438a-b159-e64a902a6b9a","orderId":"2c97e104-35ed-4c18-85d7-854a40b6b9e3","code":"PLC","createdAt":"2023-02-20T18:19:03.20162269Z","fullCode":"PLACED","id":"a38ba215-f949-4b2c-982a-0582a9d0c10e"}'

O que eu respondo para o Webhook?

Nosso webhook considera que respostas com código 202 Accepted dentro de 5 segundos significam que a integração recebeu o evento com sucesso, e por isso não deverão ser feitas mais chamadas para aquele evento. O corpo da resposta é ignorado pelo sistema, exceto para motivos de auditoria interna no caso de falhas de entrega. Para esses casos, esperamos a resposta no formato;

Casos de erro

A request webhook tem o propósito de integrar o evento com sucesso e nada mais além disso. Com esse propósito em vista, as respostas de erro devem ser usadas apenas para indicar falha na integração do evento (por evento integrado, entende-se que o evento foi recebido com sucesso pelo servidor do webhook). O mecanismo de entrega webhook aceita e reconhece erros dentro da série de erros HTTP 5xx, que podem indicar erros no recebimento ou processamento da requisição por parte do servidor. Retentativas de entrega acontecerão apenas para essa classe de erros.As respostas de erro impactam diretamente o fluxo de retentativas de entrega, por isso devem ser utilizados apenas nos casos em que exista a necessidade de um retentativa de entrega para o erro em questão.A respostas de erro podem seguir o payload especificado abaixo para detalhar e deixar claro o motivo do erro em nossa auditoria interna. Quaisquer outros campos e/ou formatos (como xml) serão ignorados.
{
  "error": "error message"
}
AtençãoCaso todas as tentativas de entrega falhem, o webhook descarta o evento, que não será mais entregue via webhook!
O número de tentativas máximo, o intervalo entre cada tentativa de entrega e o tempo para timeout fica a critério do iFood, mas qualquer atualização será comunicada com antecedência. Atualmente consideramos como timeout requests que levem mais de 5 segundo para responder e tentamos reenviar os eventos por até 15 minutos. Note que mesmo que seu endpoint responder com 202 depois de 5 segundos, ainda tentaremos realizar a request novamente.