O módulo financeiro do iFood oferece APIs que facilitam a conciliação financeira para lojas parceiras, fornecendo dados detalhados sobre faturamento e liquidação com transparência e simplicidade, a fim de garantir clareza dos lançamentos financeiros que compõem os repasses.Com as APIs Financeiras é possível automatizar a conciliação do iFood e acessar informações em larga escala, evitando erros operacionais e gerando mais valor para o negócio.Neste material, orientamos como usar este módulo de forma eficiente.
APIs do módulo financeiro
O módulo financeiro é composto pelas APIs descritas abaixo. A utilização de todas as APIs mencionadas é fundamental para garantir a obtenção dos dados necessários para a conciliação financeira de ponta a ponta da loja parceira, abrangendo desde a venda até o pagamento.API Sales ou API de Vendas fornece informações gerais sobre as vendas realizadas pela loja parceira.API Financial Events ou API de Eventos Financeiros fornece um registro completo dos eventos de fluxo de caixa (créditos e débitos) para o período de apuração de cada loja, incluindo as datas de pagamento previstas.API Reconciliation ou API de Conciliação é uma opção alternativa à API de Eventos Financeiros, com a mesma finalidade, porém fornece os dados em formato CSV.API Reconciliation ou API de Conciliação Sob Demanda é uma opção alternativa à API de Eventos Financeiros, com a mesma finalidade, porém fornece os dados em formato CSV sob demanda, ou seja, pode ser solicitada a qualquer momento.API Settlements ou API de Liquidação fornece o valor líquido repassado à loja e o valor dos recebíveis enviados às instituições financeiras.API Anticipations ou API de Antecipação informa quais repasses foram pagos antecipadamente à loja, caso ela possua um plano de antecipação contratado com o iFood.
Mudanças da versão anterior
As APIs financeiras atuais oferecem uma experiência de conciliação simplificada em comparação com a versão anterior. Essa simplificação se reflete da forma ilustrada abaixo.Recomendamos que todas as integradoras migrem para a última versão das APIs Financeiras.Baseado em eventos faturáveis do iFood, a API Financial Events e a API Reconciliation fornecem dados a nível granular de lançamentos financeiros e incorporam as regras de negócio do iFood, tornando fácil a identificação dos valores que a loja tem a receber (créditos) e a pagar (débitos).A versão legada será descontinuada em 17 de Junho de 2025 (todos os endpoints v2.0 e v2.1).
Homologação
É necessário que todas as integradoras passem pelo processo de homologação no módulo financeiro. A homologação tem como objetivo beneficiar tanto as lojas parceiras do iFood quanto as integradoras, pois assegura que a integração esteja operando corretamente, facilitando as conciliações de acordo com os critérios definidos e garantindo a segurança e a confiabilidade dos resultados apresentados às lojas parceiras.
Para realizar a homologação de aplicativo é necessário que o mesmo já esteja pronto. Os testes são feitos no APP como um todo e não apenas nas chamadas de nossas APIs.
Pedidos de homologação com cadastros de conta Pessoal/Estudante (CPF) não serão aceitos. Apenas pedidos com cadastro de conta Profisional (CNPJ).
Processo de homologação
O processo consiste em:1- Entrar em contato com o time de integração do iFood pelo Portal do Desenvolvedor e agendar a reunião de homologação. Para isto, acesse o Portal do Desenvolvedor > Suporte > Chamados > Homologação.2- A integradora receberá direcionamentos e um formulário a ser preenchido até o dia da reunião de homologação. As respostas devem demonstrar a compreensão da documentação da API, especialmente em relação aos casos de uso.Obs.: Todas perguntas devem ser respondidas consultando os dados do ambiente de teste da integradora, utilizando o header x-request-homologation = true nas chamadas dos dois endpoints.3- Durante a reunião, serão revisadas as respostas do formulário, a implementação da API e a forma como as informações são apresentadas às lojas parceiras.4- Ao final, a integradora receberá o resultado da homologação.Se aprovada: o time fornecerá as orientações para a criação do app e a integradora será reconhecida como uma integradora homologada no módulo financeiro.Se reprovada: o time pontuará as correções a serem realizadas e, após ajustes, a integradora poderá remarcar uma nova reunião de homologação.
Demonstração
Este vídeo tem o objetivo de demonstrar como utilizar as APIs financeiras para realizar a conciliação financeira de uma loja.
Definições
Esta seção explica os conceitos fundamentais do sistema financeiro do iFood. Compreender esses termos é essencial para acompanhar corretamente seus recebíveis, realizar a conciliação financeira e entender como seu dinheiro flui pela plataforma.Os conceitos estão organizados de forma lógica: começamos pelo pedido (origem de tudo), passamos pela venda e apuração, até chegarmos ao repasse (quando você recebe o dinheiro). Cada definição está conectada às demais, formando o fluxo completo da operação financeira.
Pedido
O que é: O pedido é o ponto de partida de toda operação financeira no iFood. Ele representa a solicitação de compra feita por um cliente e pode incluir produtos da sua loja e/ou serviços do iFood (como entrega).Por que é importante: Um único pedido gera múltiplos eventos financeiros ao longo de seu ciclo de vida. Não se trata apenas da venda inicial - o mesmo pedido pode originar:
✅ Venda - quando o pedido é concluído
❌ Cancelamento total - se o pedido for cancelado (antes ou depois da entrega)
⚠️ Cancelamento parcial - se um item específico for removido
💰 Ressarcimento - se o iFood assumir a responsabilidade por um problema
🔧 Ajustes - correções operacionais ou sistêmicas
Exemplo prático:
Pedido #12345 criado em 01/03/2025:→ 01/03: Venda confirmada (+R$ 50,00)→ 03/03: Item cancelado (-R$ 10,00)→ 05/03: Ressarcimento do iFood (+R$ 5,00)→ 10/03: Ajuste de taxa (-R$ 1,00)
Cada evento acima é um lançamento financeiro separado, todos vinculados ao mesmo pedido.
Venda
O que é: A venda representa a efetivação da transação comercial, independentemente de como o cliente pagou (cartão online, dinheiro na entrega, vale-refeição, etc.).Por que é importante: É a partir da venda que o iFood calcula:
📊 A base para comissões e taxas
💵 O valor inicial de repasse
📈 Suas métricas de faturamento
Atenção: Uma venda só é considerada concluída quando:
O pedido foi preparado
O pedido foi entregue (ou retirado)
Não houve cancelamento
Exemplo:
Pedido realizado: R$ 100,00Desconto da loja: -R$ 10,00Valor da venda: R$ 90,00 ← Base para cálculos do iFood
Apuração
O que é: A apuração é o processo de consolidar todos os lançamentos financeiros de um período e determinar quanto você receberá (ou deve) ao iFood.Como funciona:
Resultados possíveis:✅ Saldo positivo → Você recebe um repasse
Exemplo: +R$ 5.000,00→ Pagamento agendado conforme plano (D+30, D+7, etc.)
❌ Saldo negativo → Você deve ao iFood
Exemplo: -R$ 500,00→ Geração de boleto OU desconto no próximo repasse
Exemplo visual:
Período: 03/03 a 09/03/2025Apuração: 10/03/2025Vendas: +R$ 10.000,00Taxas iFood: -R$ 1.500,00Cancelamentos: -R$ 300,00Ressarcimentos: +R$ 150,00─────────────────────────────Saldo: +R$ 8.350,00Pagamento: 19/03/2025 (conforme plano D+30)
Competência
O que é: O mês e ano de referência dos lançamentos financeiros, usado para organização contábil.Por que é importante: A competência define em qual arquivo de reconciliação os lançamentos aparecerão, independentemente da semana de apuração.Exemplo:
Venda em 28/02/2025 → Competência: 02/2025Cancelamento em 03/03/2025 → Competência: 03/2025Mesmo pedido, competências diferentes!
Lançamentos financeiros
O que são: Registros individuais de todas as movimentações financeiras que afetam seu saldo com o iFood.
Características principais
Cada lançamento possui:
📅 Data - quando ocorreu
💵 Valor - quanto impactou (positivo ou negativo)
🏷️ Tipo - natureza da operação
🔗 Pedido associado - origem do lançamento (quando aplicável)
Período de apuração semanal
Regra fundamental: Lançamentos são registrados na semana em que ocorrem, não na semana da venda original.
**Atenção:** Um pedido criado em uma semana pode gerar lançamentos em semanas posteriores.
Exemplo cronológico
Semana 1 (01/03 - Domingo)
Pedido #789 realizado e entregue→ Lançamento: Venda de R$ 50,00
💡 **Importante:** Para reconciliar corretamente, você precisa acompanhar **todos** os lançamentos do mesmo pedido, mesmo em semanas diferentes.
Tipos de lançamento
Entenda os principais tipos de movimentações financeiras:
1. Vendas 💰
O que são: Receitas geradas por pedidos concluídos com sucesso.Quando ocorrem: Na entrega (ou retirada) do pedido.Impacto: Positivo (+)
2. Cancelamentos ❌
O que são: Estornos de pedidos cancelados após a confirmação.Quando ocorrem: No momento do cancelamento (total ou parcial).Impacto: Negativo (-)Observação: O cancelamento pode ocorrer mesmo após a venda, gerando lançamentos negativos para reverter a operação.
3. Ressarcimentos 🛡️
O que são: Compensações financeiras quando o iFood assume responsabilidade por problemas.Exemplos de situações:
Cancelamento por indisponibilidade de entregador do iFood
Problemas técnicos na plataforma
Erros operacionais do iFood
Quando ocorrem: Conforme política de ressarcimento do iFood.Impacto: Positivo (+)
4. Ajustes 🔧
O que são: Correções de valores cobrados ou creditados incorretamente.Quando ocorrem: Após análise operacional ou identificação de inconsistências.Impacto: Pode ser positivo ou negativo
Resumo de impactos na apuração
Tipo
Símbolo
Impacto
Quando registrar
Venda
✅
Positivo
Na entrega do pedido
Cancelamento
❌
Negativo
No cancelamento
Ressarcimento
🛡️
Positivo
Conforme política
Ajuste
🔧
±
Após análise
📊 **Dica:** Consulte o [módulo Financial](/docs/guides/modules/financial) para obter todos os lançamentos via API e automatizar sua reconciliação.
Reconciliação financeira
O que é: O processo de validar se o valor que você recebeu corresponde aos lançamentos registrados.
Passo a passo para reconciliar
1. Agrupe por período de apuração
Selecione todos os lançamentos da semana de 03/03 a 09/03
2. Identifique lançamentos do mesmo pedido
Use o ID do pedido para agrupar:Pedido #12345: → Venda: +R$ 100,00 → Taxa: -R$ 15,00 → Ajuste: +R$ 2,00
💡 **Lembre-se:** Eventos do mesmo pedido podem aparecer em semanas diferentes. Sempre some **todos** os lançamentos relacionados.
Impacto no repasse
Conceito fundamental: Nem todo lançamento financeiro afeta o valor que você receberá do iFood.Os lançamentos são classificados em dois grupos:
✅ Lançamentos COM impacto no repasse
Definição: Operações que alteram o valor final que você receberá (ou deverá) ao iFood.Incluem:
💳 Vendas pagas online pelo cliente
📊 Taxas de serviço e comissões do iFood
❌ Cancelamentos de pedidos já confirmados
🛡️ Ressarcimentos do iFood
🚚 Taxas de entrega do iFood
Por que impactam: O iFood intermediou o pagamento ou forneceu o serviço.
❌ Lançamentos SEM impacto no repasse
Definição: Operações registradas apenas para transparência e controle, mas que não mudam seu repasse.
Tipo 1: Pagamentos diretos à loja
Quando acontece: Cliente paga diretamente no seu estabelecimento.Métodos:
🎟️ Vale-refeição (VA/VR)
💵 Dinheiro na entrega
💳 Cartão na maquininha da loja
Por que não impacta: O dinheiro já está com você, não passa pelo iFood.
Tipo 2: Promoções da loja
Quando acontece: Você oferece descontos por iniciativa própria.Exemplos:
🛍️ "Compre 2, leve 3"
🏷️ "10% de desconto na compra"
🎫 Cupons promocionais da loja
Por que não impacta: O desconto reduz a base de cálculo, mas não gera débito adicional.
Como identificar nos relatórios
Tipo de lançamento
Impacto
Onde aparece
Venda online
✅ Sim
Relatório semanal
Vale-refeição
❌ Não
Somente controle
Taxa de serviço
✅ Sim
Relatório semanal
Promoção da loja
❌ Não
Detalhamento do pedido
Taxa de entrega iFood
✅ Sim
Relatório semanal
Dinheiro na entrega
❌ Não
Somente controle
💡 **Regra prática:** Para calcular seu repasse, considere **apenas** os lançamentos marcados como "COM impacto no repasse".
Exemplos práticos detalhados
Exemplo 1: Pedido com pagamento online
Pedido #12345 - Pagamento: Cartão onlineValor do pedido: R$ 100,00Promoção da loja (-10%): -R$ 10,00 ❌ Sem impacto──────────────────────────────────────Subtotal (base cálculo): R$ 90,00Taxa iFood (15%): -R$ 13,50 ✅ Com impacto──────────────────────────────────────Valor do repasse: R$ 76,50 ← Você receberá
Exemplo 2: Pedido com vale-refeição
Pedido #12346 - Pagamento: Vale-refeiçãoValor do pedido: R$ 50,00 ❌ Sem impacto*Taxa iFood (15%): -R$ 7,50 ✅ Com impacto──────────────────────────────────────Valor do repasse: -R$ 7,50 ← Você pagará apenas a taxa*Valor já creditado diretamente pela operadora do VA/VR
Exemplo 3: Pedido com entrega iFood
Pedido #12347 - Entrega iFoodValor dos itens: R$ 80,00Promoção loja (-15%): -R$ 12,00 ❌ Sem impacto──────────────────────────────────────Subtotal: R$ 68,00Taxa iFood (12%): -R$ 8,16 ✅ Com impactoTaxa entrega iFood: -R$ 8,99 ✅ Com impacto──────────────────────────────────────Valor do repasse: R$ 50,85 ← Você receberá
Use o [módulo Financial](/docs/guides/modules/financial) para filtrar automaticamente os lançamentos por tipo de impacto.
Entrada financeira
O que é: O valor total que o cliente pagou pelo pedido, independentemente de quem recebeu o pagamento (iFood ou loja).Por que é importante: É o ponto de partida para todos os cálculos financeiros do pedido.Quem pode receber:
🟢 iFood - pagamentos online (cartão, PIX via app)
🔵 Loja - pagamentos offline (dinheiro, cartão na entrega, VA/VR)
Exemplo:
Cliente compra R$ 100,00 no app↓Entrada financeira: R$ 100,00↓Essa é a base para calcular: • Comissões • Taxas • Repasse final
Recebedor do pagamento
O que é: A entidade (iFood ou loja) que recebe o dinheiro do cliente no momento da transação.
Cenários possíveis
1. iFood como recebedor 🟢
Cliente paga pelo app (cartão/PIX)→ iFood recebe→ iFood repassa para você (após descontar taxas)
Impacto: Lançamentos COM impacto no repasse2. Loja como recebedor 🔵
Caso A: Vale-refeição (VA/VR)
Cliente paga com VA/VR→ Operadora do cartão paga diretamente à loja→ iFood cobra apenas as taxas
Caso B: Pagamento offline
Cliente paga na entrega (dinheiro/cartão)→ Loja recebe diretamente→ iFood cobra apenas as taxas
Impacto: Pagamento SEM impacto no repasse (mas taxas têm impacto)
Resumo visual
Método de pagamento
Recebedor
Impacto no repasse
Cartão online (app)
iFood
✅ Sim
PIX (app)
iFood
✅ Sim
Vale-refeição
Loja
❌ Não*
Dinheiro na entrega
Loja
❌ Não*
Cartão na entrega
Loja
❌ Não*
*Apenas as taxas do iFood impactam o repasse
💡 **Lembre-se:** Quando a loja é o recebedor, o valor do pedido aparece nos relatórios apenas para controle. As taxas do iFood são descontadas normalmente.
Subsídios (Promoções)
O que são: Descontos aplicados ao pedido que podem ter diferentes impactos no repasse, dependendo de quem os custeou e onde foram aplicados.
Tipos de subsídios
1. 🟢 Promoção incentivada pelo iFood ou Indústria
Como funciona:
Cliente não paga o desconto↓iFood ou Indústria custeia↓Você recebe o valor integral
Exemplo:
Pedido: R$ 100,00Desconto iFood: -R$ 15,00 (cliente paga R$ 85,00)Repasse para você: Calculado sobre R$ 100,00
⚠️ **Mudança importante (Março/2024):** Antes, promoções da loja eram registradas de forma neutra (débito + crédito). Agora, são marcadas como "sem impacto no repasse" para maior clareza.
O que é: O valor sobre o qual as taxas e comissões do iFood são calculadas.Regra fundamental: A base considera apenas itens e serviços vendidos pela loja.
O que ENTRA na base de cálculo
✅ Valor dos itens vendidos
✅ Serviços fornecidos pela loja
O que NÃO ENTRA na base de cálculo
❌ Taxa de entrega do iFood
❌ Promoções da loja (itens)
❌ Promoções da loja (delivery)
❌ Promoções da rede
Data: Conforme plano contratado • D+30: ~4 semanas após a apuração • D+7: 1 semana após a apuração • D+1: 1 dia útil após a apuração
📊 **Dica:** Use as APIs para automatizar o cálculo e acompanhar o repasse em tempo real, sem precisar aguardar o fechamento da semana.
Registro de recebíveis
O que é: Mecanismo regulamentado pelo Banco Central que permite que instituições financeiras (bancos) recebam parte dos seus recebíveis futuros como garantia de empréstimos.
Como funciona na prática
Situação normal:
Você → Vende pelo iFood → iFood repassa 100% para você
Com registro de recebíveis:
Você → Vende pelo iFood → iFood divide o repasse: ├─ 60% para você └─ 40% para o banco (empréstimo)
Quando acontece
✅ Você contraiu um empréstimo com um banco
✅ O banco solicitou seus recebíveis como garantia
✅ O Banco Central aprovou o registro
✅ Uma parte dos seus repasses vai direto para o banco
Exemplo prático
Repasse da semana: R$ 10.000,00Com registro de recebíveis: Parcela empréstimo (banco): R$ 4.000,00 Valor líquido (você): R$ 6.000,00 ─────────────────────────────────────────── Total: R$ 10.000,00Nos seus relatórios: ✅ Repasse original: R$ 10.000,00 ✅ Registro recebível: -R$ 4.000,00 ✅ Valor final recebido: R$ 6.000,00
⚠️ **Importante:** O registro de recebíveis é controlado pelo Banco Central. Entre em contato com seu banco para entender as condições do contrato.
📚 **Saiba mais:** Confira detalhes completos no [blog para parceiros sobre registro de recebíveis](https://blog-parceiros.ifood.com.br/registro-de-recebiveis/).
Resumo dos conceitos-chave
Para uma visão rápida de como tudo se conecta:
1. PEDIDO criado ↓2. VENDA concluída → Gera ENTRADA FINANCEIRA ↓3. LANÇAMENTOS FINANCEIROS registrados ao longo do tempo ↓4. APURAÇÃO semanal consolida tudo ↓5. REPASSE calculado (considerando BASE DE CÁLCULO) ↓6. Pode ter REGISTRO DE RECEBÍVEIS (se houver empréstimo) ↓7. PAGAMENTO efetuado conforme plano contratado
💡 **Próximos passos:** Agora que você domina os conceitos, explore as APIs financeiras para automatizar sua conciliação e ter controle total dos seus recebíveis.
API Sales
Introdução
A API Sales ou API de Vendas é responsável por exibir todas as vendas que houveram em um determinado período, apresentado informações como status da venda, número único do pedido, método de pagamento, valor pago pelo consumidor, quem acolheu o pagamento do pedido, entre outras informações da venda relevantes para o contexto financeiro.
Atualização dos dados
As vendas são disponibilizadas na API no mesmo dia em que são realizadas. Os eventos associados a cada venda são apresentados no array orderEvents à medida que ocorrem.
Parâmetros de busca
A API é chamada utilizando os seguintes parâmetros:
merchantId: Id da loja
beginSalesDate: Data inicial da busca
endSalesDate: Data final da busca
page: Página inicial (1 por default), pois os itens são paginados
O retorno inclui todas as vendas realizadas pela loja no período especificado.
Principais campos e conceitos
Objeto saleGrossValue: O valor bruto da venda (ou GMV total) é composto por itens do pedido, entrega e taxa de serviço.
Fatores que compõem o valor bruto da venda
Definição
GMV
Existente em todo pedido?
Campo na API Sales correspondente
Itens do pedido
São produtos fornecidos pela loja parceira
GMV Loja
Sim.
saleGrossValue.bag
Entrega
Serviço de entrega que pode ser realizado tanto pelo iFood quanto pela loja parceira
GMV iFood ou GMV Loja, a depender de quem realizou o serviço
Não. Não há entrega quando o pedido foi retirado na loja pelo cliente.
saleGrossValue.deliveryFee
Taxa de serviço
Taxa cobrada do cliente pelo serviço de transação do pedido que foi realizada pelo iFood
GMV iFood
Não. A taxa de serviço iFood só é aplicada para alguns pedidos.
saleGrossValue.serviceFee
Podemos afirmar que os cálculos abaixo são corretos:Valor bruto da venda = itens do pedido + entrega + taxa de serviçoGMV total = GMV loja + GMV iFoodGMV loja = itens do pedido + entrega (quando realizada pela loja)GMV iFood = entrega (quando realizada pelo iFood) + taxa de serviçoObjeto benefitsOs benefícios são exibidos separadamente por aplicação (itens do pedido ou entrega) e por incentivador (iFood, loja, rede ou incentivador externo).Objeto deliveryContém detalhes da entrega, incluindo prestador do serviço (loja ou iFood), valor e benefícios aplicados.Objeto billingSumaryFornece um resumo financeiro atualizado do pedido no momento da consulta à API.O campo saleBalance indica o valor líquido a ser repassado à loja pelo pedido, já considerando eventuais cancelamentos, reembolsos ou ajustes de venda.O array billingEntries consolida todos os eventos financeiros relacionados ao pedido, agrupados por tipo de evento financeiro.Exemplo: Se um pedido teve um evento financeiro de comissão no valor de R$ 10,00 debitado da loja na venda e, posteriormente, o mesmo valor de comissão foi creditado à loja devido ao cancelamento do pedido, o resultado da soma de comissão será zero.Objeto paymentsContém informações sobre os métodos de pagamento utilizados no pedido, seus respectivos valores, recebedor do pagamento (loja ou iFood) e detalhes de parcelamento (quantidade e valor de cada parcela) caso tenha sido um pagamento parcelado pelo cliente.Array orderEventsApresenta a lista completa de eventos da venda, abrangendo também os eventos financeiros detalhados.
Todos os campos
Campo
Tipo
Descrição
Nulo
page
number
Número da página da consulta. Valores possíveis 0-pageCount.
Não
size
number
Tamanho de registros por página.
Não
beginSalesDate
string
Data de início do período de vendas, fornecida na query da API e levando em conta o timezone do merchant.
Não
endSalesDate
string
Data de término do período de vendas, informada na query da API, considerando o timezone do merchant.
Não
sales[]
list
Lista de vendas.
Sim
sales.id
string
Identificador do pedido.
Não
sales.shortId
number
Identificador curto do pedido.
Não
sales.createdAt
string
Data e hora em que o pedido foi criado, no fuso horário UTC.
Não
sales.type
string
Tipo da transação.
Não
sales.category
string
Categoria da venda.
Não
sales.salesChannel
string
Canal de vendas.
Não
sales.currentStatus
string
Status atual do pedido.
Não
sales.merchant.id
string
Identificador único do comerciante responsável pelo pedido.
Não
sales.merchant.shortId
number
ID curto do comerciante.
Não
sales.merchant.document[]
list
Lista de documentos associados ao comerciante.
Não
sales.merchant.document.value
string
Número do documento do comerciante.
Não
sales.merchant.document.type
string
Tipo do documento, por exemplo CNPJ, CPF.
Não
sales.merchant.name
string
Nome do estabelecimento.
Não
sales.merchant.type
string
Tipo do estabelecimento.
Não
sales.merchant.timezone
string
Fuso horário em que o estabelecimento opera.
Não
sales.saleGrossValue.bag
number
Valor bruto dos itens (bag) no pedido.
Não
sales.saleGrossValue.deliveryFee
number
Valor da taxa de entrega dentro de order (marketplace).
Não
sales.saleGrossValue.serviceFee
number
Valor da taxa de serviço cobrada do cliente.
Não
sales.benefits.benefits[]
list
Lista de benefícios usadas na order.
Sim
sales.benefits.benefits.target
string
Foco do benefício.
Sim
sales.benefits.benefits.sponsorships[]
list
Lista de sponsorships.
Sim
sales.benefits.benefits.sponsorships.name
string
Quem é o responsável pelo benefício.
Sim
sales.benefits.benefits.sponsorships.value
number
Valor monetário do benefício aplicado.
Sim
sales.benefits.benefits.totalValue
number
Valor total de todos os benefícios aplicados ao pedido.
Sim
sales.delivery.informationProvider.name
string
Nome do provedor que disponibiliza as informações de entrega.
Soma dos valores (amounts) das entradas financeiras do evento FINANCIAL_BILLED_ORDER_ENTRY mais recente, exceto aquelas cujo nome de entrada seja STORE_SUBSIDY.
Não
sales.billingSummary.billingEntries[]
list
Lista de entradas Financeiras.
Sim
sales.billingSummary.billingEntries.name
string
Nome que classifica cada entrada financeira.
Sim
sales.billingSummary.billingEntries.value
number
Quantia correspondente à entrada financeira.
Sim
sales.orderEvents[]
list
Lista de eventos de order.
Sim
sales.orderEvents.id
string
Identificador único do evento no histórico.
Sim
sales.orderEvents.fullCode
string
Código completo do evento.
Sim
sales.orderEvents.code
string
Código derivado do valor do evento (ex.: “FBOE” para FINANCIAL_BILLED_ORDER_ENTRY).
Sim
sales.orderEvents.createdAt
string
Data e hora em que o evento foi registrado.
Sim
sales.orderEvents.metadata
string
Metadata do evento.
Sim
total
number
Quantidade total de vendas localizadas no período consultado.
Não
pageCount
number
Número total de páginas necessárias para exibir todas as vendas (total / size).
A API Financial Events ou API de Eventos Financeiros oferece um registro detalhado dos eventos financeiros resultantes das operações da loja no iFood. Através dela, você pode acompanhar o fluxo de caixa (créditos e débitos) em cada período de apuração, compreendendo os valores a receber e as datas de pagamento.
Atualização dos dados
Os dados de eventos financeiros são atualizados na API em tempo quase real, à medida que ocorrem, garantindo acesso rápido às informações mais recentes.
Parâmetros de busca
A API permite filtrar eventos financeiros por período de apuração (semanal ou diário), utilizando os seguintes parâmetros:merchantId (obrigatório): Identificador único da loja (merchant).
beginDate (obrigatório): Data inicial do período de apuração, no formato AAAA-MM-DD.
endDate (obrigatório): Data final do período de apuração, no formato AAAA-MM-DD.page (opcional): Indica o número da página a ser exibida. Se não fornecida, retornará a página 1 por padrão.size (opcional): Indica o número de itens exibidos por página. Se não fornecido, o padrão é 100 itens por página.hasNextPage: Valor booleano que indica a existência de uma próxima página (true) ou se a página atual é a última (false).
Observações importantes:
A API retornará todos os eventos financeiros ocorridos dentro do período definido por beginDate e endDate, incluindo as datas de início e fim.Certifique-se de que o endDate seja igual ou posterior ao beginDate.O intervalo entre o beginDate e o endDate não pode exceder 33 dias na requisição.
Exemplos de uso correto:
Os períodos de apuração semanais iniciam-se às segundas-feiras e encerram-se aos domingos.Para consultar eventos financeiros do período de apuração entre 03/03/2025 (segunda) e 09/03/2025 (domingo), utilize:merchantId: [valor do merchantId]
beginDate: 03/03/2025
endDate: 09/03/2025Pode também ser utilizado intervalos maiores, em que o período de apuração esteja contido, exemplo:merchantId: [valor do merchantId]
beginDate: 02/03/2025
endDate: 10/03/2025merchantId: [valor do merchantId]
beginDate: 01/03/2025
endDate: 31/03/2025
Exemplos de uso incorreto:
merchantId: [valor do merchantId]
beginDate: 04/03/2025
endDate: 08/03/2025A requisição resultará em um erro, pois o período requisitado (04/03/2025 à 08/03/2025) esta dentro do período desejado (03/03/2025 à 09/03/2025), ou seja, o beginDate requisitado é maior que o dia inicial correto, e o endDate requisitado é menor que o dia final correto.
Possíveis Erros:
Se beginDate for posterior a endDate, a API retornará um erro.Se beginDate requisitado for maior que o dia inicial da apuração, e o endDate requisitado for menor que o dia final da apuração, a API retornará um erro.Se os parâmetros de data não corresponderem ao formato AAAA-MM-DD, a API retornará um erro.Se os parâmetros merchantId, beginDate ou endDate não forem passados na requisição, a API retornará um erro.
Recomendações para otimizar a utilização da API:
Recomendamos priorizar a consulta de dados em períodos semanais. Essa abordagem otimiza o tempo de resposta da API e garante a entrega de informações mais ágeis e eficientes.
Informamos que consultas mensais podem resultar em latência elevada, devido ao grande volume de dados.
Aconselhamos fortemente a implementação de um sistema de tentativas (retry) em cada solicitação à API. Isso é crucial devido à paginação dependente, onde a próxima página requer dados da anterior. O sistema deve contemplar controle de falhas e reenvio de solicitações para assegurar a recuperação completa dos dados.
Principais campos e conceitos
Os eventos financeiros são identificados pelos seguintes campos:name: contém o nome do evento financeiro, fornecendo uma identificação concisa do tipo de transaçãodescription: oferece uma descrição detalhada do evento financeiro, complementar ao nome do eventotrigger: indica o gatilho ou a ação que originou o evento financeiro. Exemplos:SALE_CONCLUDED e NO_CONCLUDED_STATUS: Transação de vendaSALE_CANCELLED: cancelamento de um pedido completo.PARTIAL_CANCELLATION_SALE,SALE_PARTIAL_CANCELLED: cancelamento de um item específico em um pedido.STORE_REFUND_REQUEST: reembolso de um pedido ou item cancelado.LOGISTIC_SHIPPING_CHARGE: solicitações de serviços de entrega.MANUAL_REBILLING: correção ou ajuste realizado manualmente.MONTHLY_FEE: mensalidade.
Identificação de Pedidos
Cada evento financeiro pode ou não estar associado a um pedido. Se estiver associado, ele terá o tipo "ORDER" e será possível identificar a qual pedido pertence através do campo "id", que é o identificador único do pedido.Um pedido pode ter vários eventos financeiros, que não necessariamente estarão na mesma página de retorno da API.Enquanto a API Financial Events se concentra nos detalhes dos lançamentos financeiros, a API Sales fornece informações mais específicas sobre os pedidos em geral. Se for necessário consultar detalhes mais aprofundados sobre um pedido, a API Sales é a opção mais adequada.
Valor Líquido Esperado a Receber pela Loja
Período de Apuração:
O iFood utiliza períodos de apuração para calcular os valores a serem repassados às lojas. Os períodos de apuração podem variar dependendo do produto:Período Semanal: Para a maioria dos produtos, o período de apuração é semanal, iniciando às segundas-feiras e encerrando aos domingos.Período Diário: Para alguns produtos específicos, o período de apuração pode ser diário.beginDate: Este campo representa a data de início do período de apuração.endDate: Este campo representa a data de fim do período de apuração.
Cálculo do Valor de Repasse:
O valor esperado de repasse para a loja é calculado com base nos eventos financeiros ocorridos dentro de um período de apuração. Para determinar o valor a ser repassado, some os valores dos eventos financeiros que impactam o repasse.value: Este campo, dentro do objeto amount, representa o valor do evento financeiro. Ele pode ser positivo (crédito) ou negativo (débito).hasTransferImpact: Este campo booleano indica se o evento financeiro afeta o valor a ser repassado à loja. Apenas os eventos com hasTransferImpact: true devem ser considerados no cálculo do valor de repasse.
Datas de Repasse:
A data esperada para a liquidação do pagamento é informada no campo expectedDate. A data de pagamento é determinada pelo plano de repasse da loja (D+1, D+7, D+30), que define o número aproximado de dias após o fim do período de apuração em que o pagamento será efetuado.
Taxas e comissão
Em eventos financeiros que envolvem taxas e comissões, você encontrará:baseValue: O valor base sobre o qual a taxa ou comissão é calculada.feePercentage: A porcentagem aplicada ao baseValue para determinar o valor cobrado.
Pedidos pagos diretamente para a loja
Pedidos pagos diretamente à loja ou a adquirentes de vale-refeição terão eventos financeiros de pagamento visíveis na API Financial Events, mas com hasTransferImpact: false. Isso indica que esses valores não devem ser considerados no repasse do iFood, pois foram recebidos diretamente pela loja. No entanto, outros eventos associados a esses pedidos, como comissões do iFood ou cancelamentos, possuem hasTransferImpact: true e, portanto, devem ser incluídos no cálculo do repasse.
Todos os campos
Campo
Descrição
Tipo
Exemplo
Nulo
page
Identificador da página atual
Integer
1
Não
size
Número máximo de itens em uma página
Integer
100
Não
hasNextPage
Indicador de existência de próxima página
Boolean
true
Não
name
Nome do evento financeiro
String
ORDER_COMMISSION
Não
description
Descrição do evento financeiro
String
FULLSERVICE_COMMISSION
Não
product
Nome do produto
String
IFOOD
Não
trigger
Nome do trigger que gerou o evento financeiro
String
ORDER_CONCLUDED
Não
competence
Ano-mês que se refere esse evento financeiro
String (YYYY-MM)
2025-03
Não
period.beginDate
Data inicial do período de apuração do evento
String
2025-03-01
Não
period.endDate
Data final do período de apuração do evento
String
2025-03-01
Não
reference.type
Indica se o evento é associado à pedido, transação ou sem referência
String
ORDER
Sim
reference.id
ID da referência
String
52e55ca2-8ba9-4224-9758-df35cb347e20
Sim
reference.date
Data da referência (ex: data do pedido)
String
2025-03-02T15:47:37.084140Z
Sim
hasTransferImpact
Indica se esse evento tem impacto financeiro
Boolean
true ou false
Não
amount.value
Valor do evento
String
-4.17
Não
billing.baseValue
Valor base considerado no cálculo do evento
String
18.12
Sim
billing.feePercentage
Porcentagem considerada no cálculo do evento
String
23
Sim
billing.installments.reference
Indica se o pagamento do pedido foi parcelado
String
1/3
Sim
billing.installments.referenceDate
Data original do pedido
String
2025-02-26
Sim
settlement.expectedDate
Data esperada de pagamento
String
2025-03-26
Não
receiver.merchantId
Identificador do merchant
String
facd4606-531c-4fea-8e73-e186890a19a5
Não
receiver.merchantDocument
Documento do merchant
String
57521985000118
Não
payment.method
Método de pagamento
String
CREDIT
Sim
payment.brand
Bandeira de pagamento
String
VISA
Sim
payment.liability
Recebedor do pagamento do cliente
String
INTERNAL ou EXTERNAL
Sim
Casos de uso
Nesta seção apresentamos um caso de uso da API de Eventos Financeiros.Considere este exemplo de resposta da API representado no payload abaixo.