Integração do iFood em múltiplos sistemas

Post para relatar problemas que acontecem quando um cliente (restaurante) usa vários sistemas integrados ao iFood ao mesmo tempo.

Somos uma software house parceira do iFood e temos um sistema de logística para restaurantes.

Nossa integração com o iFood é simples, nós precisamos apenas puxar os pedidos confirmados para dentro do nosso sistema para que o restaurante possa gerenciar sua logistica com o nosso sistema (rotas, despacho e etc).

É muito comum nossos clientes usarem nosso sistema para logistica junto com um sistema de PDV (exemplo: Programa Consumer) o que gera conflitos no uso da API do iFood quando algum dos sistemas integrados não usa a API da melhor forma.

# Mas como usar a API do iFood para que seu sistema não gere conflito com outros sistemas integrados?

Não consegui achar nenhuma recomendação do time de integrações do iFood sobre isso.

No nosso caso, temos muitos clientes em comum com o Programa Consumer e infelizmente quando o consumer está integrado com o iFood, não é possível usar nossa integração e nem o próprio gestor de pedidos do iFood funciona.

Exemplo: O gestor de pedidos do iFood funciona junto com a Foody Delivery, pois o gestor de pedido do iFood envia os comandos de integrated e confirmed na API do iFood sem fazer com que os pedidos sumam da integração (ACK).

Já no caso do consumer, depois que o pedido é INTEGRATED no consumer, ele não é mais retornado na API de eventos do iFood.

Isso acontece porque provavelmente o consumer envia um comando de ACK para o pedido (/events/acknowledgment).

Olhando a documentação do endpoint de ACK (/events/acknowledgment).

Após o e-PDV receber os eventos do IFood, para cada evento que o e-PDV conseguiu realizar o parse e integrá-lo com sucesso, o e-PDV deve enviar uma requisição confirmando o recebimento dos eventos.

Recomenda-se que o e-PDV envie uma lista de todos os eventos recebidos com sucesso de uma única vez. Importante salientar que apenas o id do evento é obrigatório.

O IFood processará as notificações e removê-los da fila de eventos do e-PDV. Na próxima requisição que o e-PDV consulta por novos eventos, os eventos previamente confirmados não farão mais parte da resposta.

Este é um grande problema quando multiplos sistemas estão integrados com o iFood, porque se um sistema executa o ACK para um pedido, o iFood limpa o evento do polling e desta forma, os outros sistemas não conseguem puxar os eventos para aquele pedido.

Nós da Foody Delivery usávamos o ack nas primeiras versões da nossa integração, mas depois de perceber o problema que ele causa, nós paramos de usar o ACK e passamos a fazer um controle interno dos eventos para não precisar usar o ACK.

Aparentemente o próprio gestor de pedidos do iFood não usa mais o ACK, pois quando usamos o gestor de pedidos, os eventos permanecem no polling do iFood, o que é bom e permite que outros sistemas usem a API em paralelo.