Mudanças na Entrega on Demand — Unificação com serviços Entrega Fácil

Eduardo Sato
ifood-developer
Published in
3 min readAug 8, 2023

Introdução

Os merchants que possuem entrega própria podem solicitar, a qualquer momento, um entregador parceiro do iFood para entregar um determinado pedido feito pelo aplicativo do iFood (pedidos on platform). Esse serviço é chamado de Entrega on Demand.

Mas, nos últimos anos, disponibilizamos também um outro serviço de entrega, chamado Entrega Fácil (também conhecido no passado como iFood Entrega). Este serviço permite solicitar uma entrega para pedidos que não foram feitos pelo aplicativo do iFood, ou seja, pedidos feitos através de outros canais de venda, como telefone, whatsapp, aplicativo ou site próprio (pedidos off platform).

Para oferecermos um melhor nível de serviço a nossos parceiros, decidimos então, unificar estes dois serviços, onde o serviço On Demand (pedidos on platform) será incorporado ao Entrega Fácil. Isso exigirá algumas mudanças na integração com as nossas APIs.

Mudanças na contratação do serviço de Entrega on Demand

Para substituir o Entrega on Demand, serão necessárias alterações nas 3 etapas desse serviço:

  • Cotação;
  • Contratação;
  • Cancelamento.
Diagrama do novo fluxo

O que muda na Cotação?

Antes da mudança, sempre que um pedido era elegível à contratação desse serviço, a integração recebia no polling o evento REQUEST_DRIVER_AVAILABILITY com o valor da taxa de entrega. Esse evento deixará de ser propagado no polling.

Após a incorporação desse serviço pelo Entrega Fácil, a integradora deverá fazer uma requisição GET /orders/{id}/deliveryAvailabilities (Módulo de Shipping) para obter a cotação sempre que necessário.

Como fica a Contratação?

Anteriormente, para realizar a contratação desse serviço, a integradora fazia uma requisição no endpoint POST /order/{id}/requestDriver (Módulo de Order). Esse endpoint também deixará de existir.

Após a junção dos serviços, a integradora deverá fazer uma requisição POST /order/{id}/requestDriver (Módulo de Shipping).

Essa requisição de contratação é assíncrona e a integradora deverá receber os seguintes eventos no polling:

  • REQUEST_DRIVER,
  • REQUEST_DRIVER_SUCCESS ou REQUEST_DRIVER_FAILED.

O que muda no Cancelamento?

Antes da mudança, ao realizar o cancelamento da solicitação de um entregador iFood, a integradora fazia uma requisição no POST /orders/{id}/cancelRequestDriver (Módulo de Order). Esse endpoint, assim como os anteriores, também deixará de existir.

Depois, a integradora deverá fazer uma requisição POST /orders/{id}/cancelRequestDriver (Módulo de Shipping).

Essa requisição de cancelamento também é assíncrona e a integradora deverá receber no polling os seguintes eventos:

  • DELIVERY_CANCELLATION_REQUESTED,
  • DELIVERY_CANCELLATION_REQUEST_ACCEPTED, ou DELIVERY_CANCELLATION_REQUEST_REJECTED

Mudanças no Entrega Fácil (iFood Entrega)

Após a unificação, para pedidos on platform, passa a ser possível cancelar somente a solicitação de entrega (sem necessariamente alterar o status do pedido). Para realizar o cancelamento da solicitação de entrega, é necessário uma requisição no novo endpoint POST /shipping/v1.0/orders/<orderId>/cancelRequestDriver, do módulo de Shipping

Ao contrário, para pedidos off platform (salesChannel = “POS”), o comportamento continua sendo o mesmo, ou seja, ao cancelar a solicitação através do endpoint POST /shipping/v1.0/orders/{id}/cancel o pedido tem seu status alterado para CANCELLED.

Datas e prazos

Os novos endpoints estarão disponíveis a partir de 02/10/2023, no Portal do Desenvolvedor. Já os endpoints antigos serão descontinuados na data de 20/11/2023.

Portanto, as integradoras terão 45 dias a partir da publicação da nova documentação para atualizar seus aplicativos.

Consulte nossa documentação completa no nosso Portal do Desenvolvedor para entender em detalhes como essas mudanças afetarão a integração com nossas APIs.

--

--