O webhook é um mecanismo de entrega de eventos server-server em tempo real. É a solução recomendada em situações onde a integradora tem acesso a vários merchants e faz o gerenciamento dos pedidos de forma centralizada. Com isso podemos evitar a limitação de múltiplos pollings para integrações com muitos merchants.
Atenção! O webhook só está disponível para aplicativos com autenticação centralizada!
Webhooks são uma alternativa ao desperdício do polling contínuo. O exemplo a seguir usa os eventos requests/create webhook para ilustrar a diferença:
O aplicativo especifica um endpoint HTTPS hospedado pelo servidor da integradora para receber eventos do webhook.
As definições a seguir explicam os conceitos relacionados com o webhook:
Veja em detalhes sobre eventos de pedidos do iFood
Veja em detalhes sobre como funciona a assinatura das mensagens no webhook
Veja em detalhes sobre como funciona a request que o webhook realiza para sua integração
Veja em detalhes sobre como funciona presença no webhook
A aba de configuração do webhook no developer portal tem um botão para testar a conexão do webhook. Esse botão gera um mock de request de presença para o webhook cadastrado. Essa request não é real, no sentido de que ela não é feita pelo serviço de webhook e por tanto não gera um heartbeat. Esse botão tem o único propósito de auxiliar a integração a simular uma request para o endpoint cadastrado.
Além disso, o developer portal tem a ferramenta para gerar pedidos de teste, que no fim acaba gerando e entregando um evento de PLACED
via polling e webhook.
Hoje tentamos entregar eventos de um pedido por até 15 minutos após a primeira tentativa de entrega. Se todas as tentativas de entrega falharem, o evento é descartado. O iFood reserva o direito de alterar o número de tentativas, tempo entre as tentativas e o tempo máximo para as tentativas (avisando possíveis reduções de tempo máximo para a última tentativa).
Os aplicativos integrados com o método de entrega de eventos por Webhook podem ser notificados caso sejam detectados erros na entrega dos eventos.
O webhook recebe um evento por requisição e, caso essas requisições falhem, seja por indisponibilidade, timeout, ou resposta de erro, nosso sistema irá enviar uma notificação automática, no email cadastrado para o aplicativo, avisando sobre os erros encontrados.
Existem alguns cenários de notificações que irão ser considerados, dado os níveis de criticidade de cada alerta detectado.
Cada aplicativo cadastrado no portal do iFood pode ter no máximo uma URL de webhook cadastrada de até 250 caracteres
A ordem de entrega dos eventos não é garantida. Por exemplo, é teoricamente possível que um evento de confirmação seja entregue antes do evento de criação (apesar de improvável). Isso se dá pois no webhook cada evento depende do tempo de processamento de cada app, então se uma app processar um pedido e imediatamente confirmar o pedido, é teoricamente possível que outra app receba a confirmação sem ainda ter criado o pedido;
O webhook garante a entrega "at least once". Isso significa que um endpoint pode receber o mesmo evento de webhook mais de uma vez. Você pode detectar eventos duplicados pelo campo id
na mensagem enviada pelo webhook;
Hoje o webhook é capaz de entregar diferentes tipos de eventos em um mesmo endpoint, mas sem possibilidade de filtros por tipo de evento ou merchant como no polling; ficando sob responsabilidade da integradora selecionar os eventos que quiser tratar.
Diferente do polling, o webhook não possui um mecanismo de acknowledgment, e embora tenha um mecanismo de retry, caso o envio falhe um número predeterminado de vezes definido pelo iFood, um evento pode ser descartado sem ser recebido pela integradora. Hoje não é possível recuperar estes eventos de forma automática, sendo necessário recorrer ao mecanismo de polling como fallback caso a integradora venha a ter alguma instabilidade por um período longo de tempo;
Hoje o polling e o webhook são sistemas totalmente independentes para entrega de eventos. Caso tenha interesse em utilizar o polling como fallback ou sistema de conciliação, é necessário enviar requests de acknowledgment para o sistema de polling. No caso do polling como fallback, recomendamos fazer o polling a cada 5 minutos. O que irá acontecer é que a maioria das requests de polling devem vir vazias (ainda devem vir poucos eventos no polling por questão de concorrência);