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

• o corpo da requisição é um JSON que pode seguir dois formatos: eventos de pedido e eventos de presença

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;

{
  "error": "error message"
}

outros campos e outros formatos (como xml) serão ignorados.

Caso a integração responda com um código diferente ou falhe em responder (e.g. timeout), o sistema considerará que a entrega falhou, e tentará novamente dentro de um intervalo de tempo razoável.

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.