logo
logo
Webhook

Visão geral

O webhook envia um evento por requisição HTTP POST com Content-Type: application/json com os seguintes parâmetros:
  • Header: X-IFood-Signature utilizado para verificar se a request veio do iFood.
Confira aqui como funciona a assinatura de uma request do webhook e como utilizá-la para validação.

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"}'
Valide a assinatura do payload assim que recebê-lo, antes de qualquer processamento ou leitura dos dados. Faça a validação diretamente no byte array, sem fazer parse do conteúdo.

Request com espaços extras

Confira o exemplo de uma request com payload equivalente ao do primeiro exemplo, 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" }'

Request formatada

Confira o 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"
}'

Request com a ordem das propriedades trocadas

Confira o exemplo de uma 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 responder ao webhook

Envie uma resposta com o código 202 Accepted em até 5 segundos para confirmar o recebimento do evento. O sistema considera essa resposta como sucesso e não tentará reenviar o evento. Ignoramos o corpo da resposta, exceto em auditorias internas para falhas de entrega. Nesses casos, envie a resposta no formato especificado.

Casos de erro

O propósito da request do webhook é integrar o evento com sucesso. Use respostas de erro apenas para indicar falha na integração, ou seja, quando o servidor não recebeu ou não processou o evento corretamente.O webhook reconhece erros HTTP 5xx como falhas de recebimento ou processamento. O sistema só faz retentativas para esta classe de erros.As respostas de erro impactam o fluxo de retentativas e devem ser usadas apenas quando for necessário tentar a entrega novamente.Ao retornar um erro, envie o payload especificado abaixo para detalhar o motivo na auditoria interna. Ignoramos quaisquer outros formatos ou campos, como XML.
{
  "error": "error message"
}
Se todas as tentativas de entrega falharem, o webhook descarta o evento. O sistema não fará novas tentativas de entrega desse evento.
O iFood define o número máximo de tentativas, o intervalo entre elas e o tempo de timeout. Informaremos qualquer atualização com antecedência. Consideramos timeout para requests com mais de 5 segundos de resposta e tentamos reenviar eventos por até 15 minutos. Se o endpoint responder com 202 após 5 segundos, o sistema ainda tentará reenviar o evento.

Veja também

FAQ