logo
logo

Docs Order

Antes de falar um pouco mais sobre o ciclo de vida de um pedido na plataforma, é importante esclarecer alguns conceitos importantes como o tipo e um momento do pedido, pois o fluxo de recepção e entrega do pedido deve variar de acordo com o tipo e o momento.

Definições

A API de Order do Ifood suporta diferentes categorias de pedidos, cada uma com características e ciclos de vida específicos. Abaixo, você encontrará uma descrição das categorias disponíveis:

categoryDescrição
FOODPedidos realizados em restaurantes, incluindo uma variedade de cozinhas e pratos. Esses pedidos são geralmente destinados à entrega ou retirada no local.
FOOD_SELF_SERVICEPedidos feitos presencialmente através de totens de autoatendimento, geralmente encontrados em locais como cafeterias e fast-foods.
GROCERYPedidos de supermercados, pet shops, farmácias e iFood Shop. Essa categoria abrange uma ampla gama de produtos, desde alimentos e bebidas até itens de cuidado pessoal e para pets.
ANOTAIPedidos originados do aplicativo Anota AI

Existem diferentes tipos de pedidos e cada um deles exige um comportamento diferente. Isso requer tratamentos específicos no aplicativo e na operação do negócio.

orderTypeDescrição
DELIVERYPedidos que devem ser entregues no endereço escolhido pelo cliente.
TAKEOUTPedidos que o próprio cliente faz a retirada no estabelecimento. Entenda todos os detalhes de um pedido Pra retirar.
DINE_INPedidos que serão consumidos no próprio estabelecimento. O cliente faz o pedido e consome a refeição no local.

Nem todos os pedidos devem ser preparados e enviados imediatamente. Em alguns casos o cliente pode agendar uma data ou horário de entrega.

orderTimingDescrição
IMMEDIATEPedidos que devem ser preparados imediatamente e enviados o mais breve possível (as soon as possible.
SCHEDULEDPedidos que não devem ser preparados imediatamente. Deve-se respeitar o horário agendado para a entrega. Entenda todos os detalhes de um pedido agendado nessa seção.

A API é orientada a eventos, sendo assim, um pedido pode ter vários eventos vinculados a ele. Segue um diagrama com os possíveis status de um pedido.

Category: FOOD

PLACED
CONFIRMED
PREPARATION_STARTED
DISPATCHED
READY_TO_PICKUP
CONCLUDED
CANCELLED

Category: FOOD_SELF_SERVICE

PLACED
CONFIRMED
CONCLUDED
CANCELLED
READY_TO_PICKUP
DELIVERED

Category: ANOTAI

PLACED
CONFIRMED
CONCLUDED
CANCELLED
DISPATCHED

Category: GROCERY

PLACED
CONFIRMED
SEPARATION_STARTED
SEPARATION_ENDED
DISPATCHED
ARRIVED
CONCLUDED
CANCELLED

Além desses status, existem vários outros eventos vinculados a um pedido que não afetam o status dele. Nessa seção você tem mais detalhes de todos esses eventos possíveis.

Fluxo de integração

Etapas da recepção de um pedido.

ClientAPI1- Get new ordersGET /events:pollingEvents (without ACK)2- Received eventsAcknowledgmentPOST /events/acknowledgment3- Get order detailsGET /orders/{id}order details4- Confirm orderPOST /confirmGet result of confirm requestGET /events:pollingCONFIRMED (CFM)5- Order is ready to delivery or takeoutPOST /dispatch or readyToPickupClientAPI

Para receber novos pedidos, você deve fazer requests no endpoint de polling regularmente a cada 30 segundos ou registrar um webhook para receber eventos

Veja em detalhes sobre como utilizar o endpoint de polling para receber eventos de pedidos

Saiba mais

Veja em detalhes sobre como utilizar o webhook para receber eventos de pedidos

Saiba mais

Antes de confirmar ou cancelar um pedido, é necessário obter os detalhes do mesmo para que o usuário do seu aplicativo possa verificar se conseguirá preparar e entregar esse pedido, como por exemplo verificar se tem todos os itens necessários e se tem disponibilidade para efetuar a entrega no endereço informado.

Através do endpoint GET /orders/{id} você pode obter todos os detalhes de um pedido.

Esse endpoint retorna o código 200 e o conteúdo do pedido. Caso seja informado um id inválido na request, pedido ainda não está disponível ou o id de um pedido antigo o endpoint retorna 404.

Pedido ainda não disponível Em alguns casos pode acontecer do detalhe do pedido ainda não estar disponível quando o evento PLACED é recebido. Isso acontece porque o sistema de eventos e o sistema de detalhe de pedido funcionam em paralelo, sendo possível que o evento de PLACED seja entregue antes do detalhe de pedido estar disponível. Para mitigar esse problema, recomendamos a implementação de um mecanismo de retry para obter os detalhes do pedido. Se um retorno 404 for recebido, o sistema deve tentar novamente após um intervalo, utilizando uma estratégia de retry como exponential backoff, por até 10 minutos. Não faça retentativas infinitas, para evitar que seu aplicativo seja bloqueado.

Pedidos antigos A API mantém os detalhes dos pedidos por apenas 7 dias a partir da data do pedido. Caso seja consultado um pedido com mais de 7 dias ele não será encontrado. Cuidado para não consultar repetidamente pedidos antigos para evitar ser bloqueado temporariamente devido ao rate limit.

Nessa seção você encontrará todos os detalhes do payload de um pedido:

Veja em detalhes todos os campos que um pedido pode trazer

Saiba mais

É obrigatório consultar detalhes do pedido Não é permitido confirmar um pedido sem antes consultar os detalhes do mesmo. Se o aplicativo tentar confirmar um pedido sem ter obtido os detalhes, a requisição de confirmação pode retornar 202 mas depois será descartada internamente.

Após obter os detalhes do pedido, o usuário do aplicativo deve tomar uma decisão: confirmar ou cancelar esse pedido. Para confirmar um pedido você deve utilizar o endpoint: POST /confirm

Em caso de sucesso na solicitação, você receberá o código de resposta 202 (accepted). O processamento dessa requisição é assíncrono e o resultado será retornado no próximo polling. É possível que uma request de confirmação seja descartada por alguns motivos, dentre eles, por exemplo, se o pedido já havia sido cancelado anteriormente.

Prazo para confirmação Existe um tempo máximo para confirmação dos pedidos. Caso ultrapasse esse período, o pedido é cancelado automaticamente.

Limites

  • Pedidos IMMEDIATE: até 8 minutos após a data do pedido (createdAt)
  • Pedidos SCHEDULED: até 8 minutos após o horário de início do preparo (preparationStartDateTime)

Penalidades A loja pode ser fechada temporariamente se não confirmar pedidos dentro do prazo.

Veja o template de comanda para imprimir o pedido nessa seção.

Para informar o início de preparo do pedido, você deve utilizar a requisição /startPreparation.

Esse evento deve ser gerado somente depois da confirmação e antes de despachar o pedido. Caso a requisição seja feita antes ou depois, ela será ignorada.

Essa requisição é opcional mas o seu uso é recomendado para oferecer uma melhor experiência para o usuário, principalmente nos casos de pedidos agendados e quando você utiliza o evento RECOMENDED_START_PREPARATION para otimizar a sua operação e preparar o pedido no horário recomendado de acordo com a previsão de chegada do entregador.

Preparo inteligente O evento RECOMENDED_START_PREPARATION é gerado pelo iFood somente para pedidos com entrega feita pelos nossos entregadores parceiros e somente para as lojas que habilitaram o Preparo Inteligente. Em todos os outros cenários, deve-se observar o campo preparationStartDateTime que é disponibilizado nos detalhes do pedido. Para mais detalhes sobre o Preparo inteligente, acesse esse material.

Pedidos que não são entregues no endereço do cliente, como "Pra Retirar" não devem ser despachados. Nesse caso, o aplicativo deve enviar a request /readyToPickup para notificar o cliente que o pedido está pronto e pode ser retirado.

Para pedidos "delivery", é possível enviar o /readyToPickup mas o cliente não recebe nenhuma notificação no aplicativo. Para esses casos, quando a entrega é feita por entregadores parceiros iFood, o entregador pode receber a notificação de que o pedido está pronto para ser retirado. Ainda assim, quando o pedido sair para a entrega, é preciso enviar a request /dispatch que gera uma notificação para o usuário informando que o pedido dele saiu para entrega. Quando a entrega é feita pelos entregadores parceiros do iFood não é preciso enviar essa request, pois ela é gerada automaticamente quando o pedido é coletado pelo entregador parceiro.

Quando habilitada a validação do código de coleta, a pessoa entregadora precisará informar ao merchant um código de verificação. O operador do merchant deve então comparar o código informado com o código que ele tem acesso via o atributo pickupCode disponível nos detalhes do pedido, seja impresso na nota ou disponível numa tela no sistema. Isso evita a entrega de pedidos errados à pessoa entregadora e consequentemente ao cliente.

Quando a entrega do pedido é feita por uma pessoa entregadora parceira do iFood ("deliveredBy"="IFOOD") a pessoa entregadora faz a confirmação da entrega através de um aplicativo disponibilizado pelo iFood. Quando a entrega do pedido é feita pelo merchant ("deliveredBy"="MERCHANT") o merchant pode compartilhar com seus entregadores um site que permite que eles façam a confirmação da entrega. Para isso a pessoa entregadora deve acessar https://confirmacao-entrega-propria.ifood.com.br/ e informar o código localizador do pedido. O localizador pode ser encontrado no campo phone.localizer e deve ser impresso na comanda que acompanha o pedido para facilitar a digitação por parte do entregador.

Não é possível concluir um pedido através da API. O evento de CONCLUDED é gerado somente pelo próprio iFood.

Quando o iFood conclui o pedido?

RESTAURANT, PHARMACY, PET

  • Pedidos Imediatos:

    • Entrega iFood (Fullservice): No momento da entrega do pedido ou 6 hrs + deliveryTimeInSeconds após o CONFIRMED
    • Entrega Merchant (Marketplace): 4 hrs + deliveryTimeInSeconds após o CONFIRMED
  • Pedidos Agendados:

    • Entrega iFood (Fullservice): No momento da entrega do pedido ou IDP: 6 hrs + deliveryTimeInSeconds após o scheduling.to
    • Entrega Merchant (Marketplace): 4 hrs + deliveryTimeInSeconds após o scheduling.to

MARKET, HIPERMARKET

  • Pedidos Imediatos:

    • 13 hrs + deliveryTimeInSeconds após o CONFIRMED
  • Pedidos Agendados:

    • 13 hrs + deliveryTimeInSeconds após o scheduling.to

*deliveryTimeInSeconds é uma configuração do merchant

Um pedido pode ser cancelado por vários motivos e a iniciativa de cancelar um pedido pode partir da loja, do cliente ou do iFood. Pode acontecer também do Entregador solicitar o cancelamento em alguns cenários, como por exemplo quando não encontra o cliente no endereço de entrega.

Regras de cancelamento Conheça todas as condições e regras para cancelamento de um pedido: https://portal.ifood.com.br/cases/faq/jornada-do-cancelamento#

As regras de cancelamento podem variar de acordo com o momento do pedido (antes ou depois da confirmação). Neste sentido, para executar a solicitação de cancelamento através do endpoint /requestCancellation é necessário informar um código de cancelamento válido. A lista de códigos de cancelamento válidos para um pedido pode ser obtida através do endpoint /cancellationReasons.

Seguem alguns exemplos de código de cancelamento e seus motivos na tabela abaixo:

CódigoMotivo
501PROBLEMAS DE SISTEMA
502PEDIDO EM DUPLICIDADE
503ITEM INDISPONÍVEL
504RESTAURANTE SEM MOTOBOY
505CARDÁPIO DESATUALIZADO
506PEDIDO FORA DA ÁREA DE ENTREGA
507CLIENTE GOLPISTA / TROTE
508FORA DO HORÁRIO DO DELIVERY
509DIFICULDADES INTERNAS DO RESTAURANTE
511ÁREA DE RISCO
512RESTAURANTE ABRIRÁ MAIS TARDE

Outros códigos
Existem outros códigos de cancelamento de uso exclusivo do iFood. Por isso é importante que você trate o campo motivo como string no seu aplicativo.

Penalidades Evite cancelar pedidos! O excesso de cancelamentos pode resultar em algumas penalidades como por exemplo ter a loja fechada temporariamente na plataforma.

Validação do cancelamento A solicitação de cancelamento não garante que o pedido está cancelado. Ao enviar uma request /requestCancelation , você receberá como resposta o código 202 (accepted). Isso não significa ainda que o pedido foi cancelado. Significa que a requisição foi aceita e será processada pelo serviço de cancelamento. Como resultado dessa solicitação, você poderá receber no próximo polling um dos seguintes eventos:

  • CANCELLATION_REQUEST_FAILED
  • CANCELLED

O pedido só é cancelado quando é gerado o evento de CANCELLED..

ClientAPIService CancellationGET /orders/{id}/cancellationReasonsCancel CodesPOST /orders/{id}/requestCancellationAccepted (202)/requestCancellationRules validationCAN or CARFGET /events:pollingCAN or CARFClientAPIService Cancellation

O cliente também pode solicitar o cancelamento de um pedido. Isso só é permitido em alguns momentos como antes da confirmação, durante o preparo e após conclusão.

Para certos cenários de solicitação de cancelamento, pode ser oferecida a oportunidade para o parceiro negociar o cancelamento com o cliente. Essa negociação é conduzida por meio da Plataforma de Negociação para Pedidos.

A Plataforma de Negociação para Pedidos é uma ferramenta destinada a facilitar, gerenciar e agilizar negociações entre duas partes, com o propósito de resolver questões relacionadas a PEDIDOS. Ela atua como intermediária e possibilita uma comunicação eficaz entre as partes envolvidas, permitindo a troca de propostas e facilitando a busca por acordos de forma eficaz.

Para maiores detalhes:

Existe um terceiro cenário em que a iniciativa do cancelamento pode partir do iFood. Isso pode acontecer de maneira automática (pedidos não confirmados dentro do prazo) ou de maneira manual através do nosso time de atendimento. Nesses casos o evento de cancelamento (CAN) será disponibilizado através do endpoint events:polling. No conteúdo do evento tem as informações do motivo do cancelamento.

Caso o cliente tenha algum problema com o seu pedido, como a falta de um item, é possível que ocorra um cancelamento parcial desses itens que não foram entregues. Quando isso acontecer será disponibilizado um evento de ORDER_PATCHED através do endpoint de polling, indicando que houve alguma alteração nesse pedido.

Um pedido poderá ser cancelado parcialmente nos seguintes cenários:

  • Se o pedido foi entregue incompleto
  • Se o item estava inapropriado para consumo
  • Se o item estava errado
  • Se o item estava revirado

Nesses cenários, podemos ter 2 tipos de ORDER_PATCHED:

Alteração de item (CHANGE_ITEMS)

Quando há alguma alteração na quantidade ou unidade de medida (g, kg, ml, L) de algum item do pedido.

Exclusão de item (DELETE_ITEMS)

Quando um item é removido do pedido. Isso pode acontecer quando o pedido é entregue faltando algum item. Exemplo: quando a loja esquece de enviar o refrigerante. Nesse cenário, o cliente pode entrar em contato com o time de atendimento do iFood que pode então registrar a exclusão do item.

Tratamento do evento de ORDER_PATCHED

As alterações podem gerar impactos no faturamento (valores a receber do iFood) e também nos relatórios de vendas/conciliação.O tratamento desse novo evento vai garantir que não haverá divergências tanto na conciliação como nos valores dos repasses a serem recebidos do iFood.

Outros tipos de ORDER_PATCHED Existem outros tipos de eventos de ORDER_PATCHED que podem ser gerados em outros cenários de ruptura e atualmente só estão disponíveis para mercados:

  • "changeType": "ADD_ITEMS"
  • "changeType": "REPLACE_ITEMS"

A Plataforma de Negociação para Pedidos é uma ferramenta destinada a facilitar, gerenciar e agilizar negociações entre duas partes, com o propósito de resolver questões relacionadas a PEDIDOS. Ela atua como intermediária e possibilita uma comunicação eficaz entre as partes envolvidas,permitindo a troca de propostas e facilitando a busca por acordos de forma eficaz.

Informações do entregador

Os detalhes do entregador são entregues através do evento ASSIGN_DRIVER.

Rastreio do pedido

É possível rastrear a entrega do pedido através do endpoint /tracking. Além da posição, retorna também o pickupEtaStart e deliveryEtaEnd. Com essas informações o usuário do seu aplicativo, além de ter mais transparência conseguirá, por exemplo, automatizar o início do preparo do pedido e otimizar sua operação.

CampoDescrição
latitudeLatitude do entregador no momento da consulta. Pode ser null quando ainda não recebemos a posição do entregador.
longitudeLongitude do entregador no momento da consulta. Pode ser null quando ainda não recebemos a posição do entregador.
expectedDeliveryData/hora estimada para entrega do pedido. Pode ser null quando ainda não recebemos a posição do entregador.
pickupEtaStartTempo estimado em segundos até a origem (coleta do pedido). Pode ser 0 ou null quando o entregador chega ao local de coleta ou negativo quando a coleta está atrasada.
deliveryEtaEndTempo estimado em segundos para entrega do pedido. Pode ser 0 ou null quando o entregador chega ao local de entrega.
trackDateData/hora da consulta. Pode ser null quando ainda não recebemos a posição do entregador.

O rastreamento só está disponível para pedidos entregues pela logística iFood.

Disponibilidade dos dados e intervalo de consulta Deve ser utilizado somente depois que o evento ASSIGN_DRIVER é gerado e pode ser consultado de 30 em 30 segundos. O endpoint poderá retornar 404 até que todas as informações sobre a entrega estejam disponíveis. Nesse caso você deve fazer uma nova consulta depois de 30 segundos.

Rate Limit Em caso de mal uso, o aplicativo poderá ser bloqueado pelas políticas de rate limit e throttling.

Atenção O serviço de solicitação de entrega deste módulo será descontinuado e está atualmente em processo de migração para o módulo de Shipping. Esta medida tem como objetivo aprimorar e unificar a experiência de integração. mais detalhes na seção

Mesmo que a loja possua entregadores próprios é possível contratar o serviço de entrega de entregadores parceiros do iFood para um pedido específico o que pode ser útil em situações em que ocorra uma sobrecarga ou falta de entregadores próprios.

Elegibilidade Esse serviço não está disponível para qualquer pedido. O pedido só será elegível quando passar por alguns critérios como:

- O merchant está em um modelo de negócio que possibilite essa solicitação (caso o merchant seja fullservice, o pedido já é ~~entregue pela nossa logística e não é possível solicitar um entregador parceiro)~~ - o pedido é delivery (não é possível solicitar nos pedidos Pra Retirar) - a área da entrega é coberta pelos entregadores parceiros

Quando o pedido é elegível, a loja receberá após a confirmação do pedido o evento REQUEST_DRIVER_AVAILABILITY com o campo available:true e no campo quote você terá a cotação do valor que será cobrado por esse serviço.

Mais detalhes sobre o quote:

CampoDescrição
originalvalor base do serviço
discountvalor do desconto caso tenha alguma promoção aplicada nesse pedido
finalvalor final cobrado pelo serviço (original - discount)

Para solicitar o entregador concordando com a cotação retornada, utilize o seguinte endpoint: /requestDriver

Cuidado Essa ação é irreversível. Depois de solicitar um entregador, não será possível cancelar esse serviço. O custo pelo serviço será cobrado do parceiro nos próximos repasses.

Esse endpoint é assíncrono. Quando sua requisição for processada você receberá um evento REQUEST_DRIVER confirmando que a requisição foi feita e em seguida o resultado da solicitação, que pode ser: REQUEST_DRIVER_SUCCESS ou REQUEST_DRIVER_FAILED.

Veja todos os detalhes desses eventos nessa seção.

ClientAPIPollingGET /events:pollingREQUEST_DRIVER_AVAILABILITYRequest DriverPOST /orders/{order-uuid}/requestDriverPollingGET /events:pollingREQUEST_DRIVERPollingGET /events:pollingREQUEST_DRIVER_(SUCCES/FAILED)ClientAPI

Cancelamento de Entrega Sob Demanda

Para lojas parceiras que possuem entrega própria e que eventualmente contratam o serviço de Entrega Sob Demanda do iFood, em alguns casos pode ser necessário o cancelamento da solicitação de um entregador iFood. Neste caso, a loja pode cancelar somente a entrega sob demanda sem a necessidade de cancelar o pedido. O cancelamento da entrega sob demanda deve ser realizado através do endpoint POST /orders/{id}/cancelRequestDriver.

O cancelamento só será efetuado se ele for solicitado antes do aceite do entregador, neste caso nenhuma taxa será cobrada da loja. Caso seja necessário realizar o cancelamento após do aceite do entregador, deve seguir as regras estabelecidas em Cancelamento de pedido.

O endpoint é assíncrono. Quando sua requisição for processada a loja receberá um evento DELIVERY_CANCELLATION_REQUEST_ACCEPTED, em caso de sucesso, ou DELIVERY_CANCELLATION_REQUEST_REJECTED, em caso de falha. Veja todos os detalhes desses eventos nessa seção.

Importante A ação é irreversível. Após cancelar a solicitação de um entregador, não será possível reverter esse serviço. Para que um novo entregador seja solicitado, uma nova solicitação de entregador deve ser realizada.

É possível que algumas entregas realizadas por parceiros iFood sejam agrupadas. Isso acontece quando os nossos algoritmos de otimização identificam 2 pedidos com rotas de entrega parecidas ou complementares. Quando isso acontecer a API disponibilizará um evento de DELIVERY_GROUP_ASSIGNED.

Eventualmente um entregador parceiro pode ter algum problema para realizar a entrega de pedidos agrupados. Quando isso acontecer a API disponibilizará um evento de DELIVERY_GROUP_CANCELLED.

Testes

Existem duas formas de se gerar pedidos de teste:

  • Geração automática de pedidos
  • Simulando uma compra normal pelo aplicativo ou site do iFood

Veja a seguir as principais diferenças entre elas:

Nesta modalidade, é possível gerar um pedido de teste ao clique de um botão. Este pedido será gerado com informações pré-estabelecidas, tais como: endereço de entrega, itens de catálogo e forma/meio de pagamento padrão.

Para geração automática de um pedido de teste , basta seguir o passo a passo informado abaixo:

1- Fazer login no Portal do Desenvolvedor

Faça login com seu email no Portal do Desenvolvedor.

2- Acessar o menu Testes da sua conta

Localize a opção "Testes" clicando sobre seu nome de usuário na parte superior direita ou no menu lateral da esquerda.

3- Pressionar o botão "Gerar pedido de teste"

Localize o botão "Gerar pedido de teste" no canto superior direito. Ao pressioná-lo, um modal de seleção de loja deverá se abrir.

4- Selecionar uma loja de teste

Selecione a loja onde deseja gerar o pedido na lista de lojas disponíveis.

5- Confirme a geração do pedido

Pronto! Seu pedido foi criado com sucesso e agora você poderá consultá-lo pela merchant-api e pelo site/aplicativo do iFood.

Pedido gerado

Após a geração do pedido, um modal de sucesso se abrirá contendo nome da loja, ID do pedido e email do usuário de teste utilizado. Com esses dados, você pode acompanhar e manipular o pedido utilizando os módulos da merchant-api.

Usuário de teste

O usuário é o "cliente/consumidor" com o qual vai ser feito o pedido. Com ele você poderá acessar o aplicativo/site do iFood, em modo de teste, para acompanhar o pedido do ponto de vista do cliente. Se o usuário não existir, o serviço irá buscar uma conta de testes com o email do desenvolvedor cadastrado no Developer Portal. Se esse também não existir, ou já for usado em outra conta, o pedido de teste será feito para o cliente padrão noreply@developer.ifood.com.br. Neste caso, não será possível acompanhar seus pedidos de teste pelo aplicativo do iFood.

Para gerar um pedido de teste com informações personalizadas (ex: escolher um item de catálogo, meio/forma de pagamento etc), é preciso simular uma compra normal pelo aplicativo ou site do iFood conforme os passos abaixo:

1- Fazer login no site ou aplicativo

Faça login no site ou aplicativo do iFood com o seu email de desenvolvedor. No menu "Testes" do portal do desenvolvedor você encontra o email cadastrado na seção "Usuário de Testes".

2- Configurar endereço de teste

No topo do site, ou aplicativo clique em "Entregar Em" e pesquise pelo endereço "Ramal Bujari, 100" e depois confirme a localização. No campo bairro informe "Bujari" e clique em "Salvar Endereço".

3- Abrir a loja

As lojas de testes, já vem configurados com o funcionamento de 24 horas por dia todos os dias da semana, mas para que ela fique aberta na plataforma é necessário que seu aplicativo esteja conectado. Portanto, é necessário que você faça requests no endpoint /events:polling regularmente para que ela se mantenha aberta.

4- Localizar a loja teste

Agora, na barra de pesquisa, digite o nome da sua loja de teste, procure na listagem e selecione-a.

Perfil modo teste

Alguns usuários possuem o perfil "Somente Teste" mas alguns outros perfis podem fazer pedidos também em modo de produção. Se esse for o seu caso, e se nenhuma loja de teste aparecer nos resultados de pesquisa, verifique se o modo de teste está habilitado.

Para habilitar o "Modo Teste", clique em "Perfil", depois em "Editar Dados" e em seguida clique no ícone para habilitar.

Caso não apareça nenhuma loja de teste e você não tem a opção de habilitar o modo teste, abra um chamado para que nosso time de atendimento possa te ajudar.

Verifique se o seu aplicativo está fazendo polling regularmente Caso a sua loja de teste apareça como fechada, certifique-se de que o seu aplicativo esteja fazendo polling e as outras condições de abertura.

5- Adicionar itens

Adicione alguns itens do seu catálogo ao pedido até atingir o valor mínimo do pedido.

6- Fechar pedido

Escolha a forma de pagamento e depois clique no botão para finalizar o pedido. Sempre que possível, escolha pagar na entrega e de preferência em dinheiro. Assim você não precisa informar dados de cartão para fazer testes.

Pedido de teste com pagamento em cartão Caso queira fazer um pedido de teste com cartão de crédito, você pode utilizar os dados abaixo. CC: 4111 1111 1111 1111 Data: 03/2030 CVV: 737

Pedido de teste com pagamento via PIX ou Débito em Conta Ao fazer um pedido de teste, não utilizar os meios de pagamento via PIX ou Débito em Conta.

Pronto! Seu pedido foi feito com sucesso! Agora você receberá os eventos desse pedido através da API. Para mais detalhes consulte a seção Utilizando a API.

Para que você possa gerar pedidos de testes com cupons de descontos, disponibilizamos alguns cupons para isso. Para utilizá-los basta inserir um dos códigos abaixo antes de fechar o seu pedido clicando no botão "Adicionar Cupom".

Cupom (Brasil)Cupom (Colômbia)targetsponsorship
VOUCHER_IFOODVOUCHER_IFOOD_COCARTIFOOD
VOUCHER_RESTVOUCHER_REST_COCARTMERCHANT
VOUCHER_ENTGRATISVOUCHER_ENTGRATIS_CODELIVERY_FEEIFOOD

Consulte a seção Cupons de Desconto para ter todos os detalhes sobre os tipos de cupons.

Vouchers do tipo ITEM e PROGRESSIVE_DISCOUNT_ITEM Não disponibilizamos vouchers de testes do tipo ITEM pois nesse cenário é necessário criar uma campanha específica para um item do catálogo. Utilize os exemplos abaixo para mapear no seu aplicativo.

Exemplo (target ITEM)

"benefits": [
  {
    "value": 4.99,
    "target": "ITEM",
    "targetId": "1",
    "sponsorshipValues": [
      {
        "name": "IFOOD",
        "value": 4.99
      },
      {
        "name": "MERCHANT",
        "value": 0
      }
    ]
  },
  {
    "value": 4.99,
    "target": "PROGRESSIVE_DISCOUNT_ITEM",
    "targetId": "2",
    "sponsorshipValues": [
      {
        "name": "IFOOD",
        "value": 4.99
      },
      {
        "name": "MERCHANT",
        "value": 0
      }
    ]

Outros conteúdos que podem ser do seu interesse: