Como integrar os dados do delivery no Visio OS, app por app

por Lorenzo Lopez Head of Content, Visio 17 de out. de 2026

Para integrar os dados do delivery, trate cada app como uma fonte própria, por loja, e junte todas ao PDV e ao banco da mesma loja, na mesma linha do tempo, como faz a camada de Dados do Visio OS. Cada loja ganha o que vendeu em cada marketplace, o que cada um cobrou e quando pagou, com delivery e balcão separados na origem e somados só na pergunta. O que muda de app para app é o caminho de entrada, e este guia mostra o que vale para todos e o que cada um documenta.

Visio aqui é a Visio de operação de lojas (visio.ai), o sistema para quem toca várias lojas, não o Visio da Microsoft, de diagramas. A camada de Dados do Visio OS é a camada 1 de 9 do sistema e conecta toda fonte que o seu negócio roda, estrutura e deixa pronto pra IA. Esta é a página-mãe do cluster de delivery. As páginas de cada app estão em como conectar o iFood, como integrar os dados do iFood com o ERP, como integrar os dados do Rappi e como integrar os dados do Aiqfome.

Delivery é uma classe de fonte

A camada de Dados trabalha por classes de fonte: ERP e PDV, nota fiscal, bancos, delivery, os aplicativos que o time usa, câmeras e sensores e o uso das próprias ferramentas. O delivery é uma dessas classes, e a razão de ser uma classe é prática. Qualquer app novo que a loja passe a usar cai no mesmo desenho, e o grupo não precisa esperar por um conector com o nome dele.

Isso responde a uma pergunta de quem planeja: «o meu app está na lista?». A camada não é uma lista fixa de conectores. A promessa é sobre a classe e sobre o que a Visio integra: integra com todos os bancos do Brasil e com centenas de ERPs, e o que ainda não está integrado, a Visio ajuda a integrar em menos de 24 horas. Quais apps estão ligados numa operação é definido no mapeamento daquele cliente.

O que a classe entrega, para qualquer app, é o que a fonte do canal traz: o que cada loja vendeu no marketplace, o que ele cobrou e quando pagou. Essas três perguntas são as que o PDV não responde sozinho, e é nelas que o guia se apoia.

Quando a mesma loja está em mais de um app

Uma loja pode estar em mais de um app ao mesmo tempo. Cada app tem painel, regras, cobranças e datas de pagamento próprias. Quem fecha o mês baixa um relatório de cada um e soma à mão.

A camada resolve isso com três escolhas de desenho.

Cada app é uma fonte. O iFood, o Rappi e o Aiqfome entram separados, cada um pelo caminho que existe. Nenhum é uma coluna a mais na planilha do PDV.
A loja é a unidade. O mesmo CNPJ e a mesma loja significam a mesma coisa em todas as fontes. A pergunta atravessa os apps porque todos apontam para a mesma loja.
Uma definição por número. Receita líquida do delivery, quais impostos, qual taxa de delivery: escritos uma vez pela Visio, em vez de uma vez por app ou por planilha.

O resultado é que a soma entre apps e a comparação entre eles são perguntas. A comparação entre os canais só é justa se a taxa de cada um for lida com a mesma definição, e é isso que a escrita única garante.

Como avaliar a integração de um app de delivery: 6 critérios

Use os critérios abaixo em qualquer app, de qualquer tamanho.

Quem libera o acesso. O caminho começa no app, e o grupo precisa saber quem decide antes de planejar o resto.
O que atravessa. Vendas, cobranças e pagamentos são perguntas diferentes; defina qual a sua pergunta usa.
Por loja. Cada número tem de cair na loja certa, com o mesmo significado do PDV e do banco.
Separado na origem. Delivery e balcão não se misturam na entrada. A soma é na pergunta.
Um app por vez. Cada app é uma fonte própria, e a definição de cada número é a mesma em todos.
Quem mantém. Os apps mudam a documentação por conta própria, e alguém do lado do grupo precisa ser dono do vínculo.

Os caminhos que valem para qualquer app

São quatro, e a escolha depende do que o app documenta. Os três primeiros nascem no app ou no ecossistema dele. O quarto é o que a camada de Dados faz com qualquer um.

1. A API do próprio app

É o caminho de programa. Onde o app publica uma API, o dado vem da origem e a leitura não depende de arquivo. O mérito é ler o dado na origem. O custo é o de qualquer integração própria: o acesso, a manutenção quando a documentação muda e a estrutura que vem depois. A API entrega o dado do app; a definição, a junção com o PDV e a permissão por loja continuam por conta de quem constrói.

2. O relatório ou a exportação do portal do parceiro

É o caminho de arquivo, onde o app oferece um. Não exige desenvolvimento: alguém baixa, alguém importa. O risco é o do arquivo, porque o número depende de quem fez e a frequência é a de quem baixa. Funciona para uma loja; com várias, exportar é trabalho diário.

3. A integração do PDV ou do ERP com o app

Se o PDV ou o ERP já traz os pedidos do app, o dado chega ao sistema de registro e o fornecedor mantém a ponte. O que cada integração traz é definido por cada fornecedor, e a documentação dele é a fonte. O limite é o de qualquer ponte: liga dois sistemas e deixa a loja e o resto da operação de fora.

4. O app como fonte da camada de Dados do Visio OS

A camada entra depois dos caminhos acima. Cada app entra pelo caminho que existe: por API onde há uma, por exportação ou relatório onde não há, e por um caminho de extração homologado quando nenhum dos dois serve. O extrato do banco entra por Open Finance, com o consentimento do titular da conta, e a nota fiscal pelo certificado digital de cada CNPJ. A frequência é de pelo menos todo dia, cada fonte na sua frequência de extração.

Quando nenhum caminho está claro, a regra é uma só: verifique com a Visio se já existe forma homologada ou parceiro integrador antes de construir. A Visio não extrai dado contra os termos de uso de um sistema, e o que um app não libera não entra por outra porta.

O que cada app documenta

Os três apps abaixo foram consultados em 12/10/2026, e o que segue é o que cada página pública diz. Cada um tem a sua página, com o detalhe.

O iFood publica um Portal do Desenvolvedor com documentação pública, em que o caminho é criar conta, criar aplicativo, solicitar acessos e passar pela homologação (Portal do Desenvolvedor do iFood). Traz um módulo Financial, com Sales, Settlement, Reconciliation On Demand e Financial Events. A consulta não localizou página sobre a exportação do Portal do Parceiro.

A Rappi publica uma referência de API em que as credenciais só saem depois de contato com o ponto focal da Rappi e de aprovação (Portal de desenvolvedores da Rappi). A API cobre pedidos, cardápio, disponibilidade, lojas, webhooks e financeiro, e o Portal Partners deixa baixar o resumo de pagamento, em formato que a página não indica.

O Aiqfome tem, no site de parceiros, a seção «Soluções integradas», sem documentação de API nem portal de desenvolvedores, e a integração aparece por PDVs homologados (Aiqfome para parceiros). A página do gestor de pedidos não trata de exportação.

Os três têm em comum um fato: nas páginas consultadas, nenhum publica um MCP próprio. A sua IA lê o delivery pelo MCP da Visio, depois que ele entrou na camada, com o seu login. Onde um app não documenta API nem exportação, a célula dos comparativos diz que não foi possível confirmar, e o próximo passo é perguntar à Visio sobre a forma homologada.

Comparativo dos caminhos para integrar o delivery

A tabela descreve mecanismo. Onde a fonte não diz, a célula diz que não foi possível confirmar.

Critério	API do app	Relatório do portal do parceiro	Integração do PDV ou do ERP	Camada de Dados do Visio OS
Quem libera	O app, pelo caminho que ele define	Quem opera a conta no portal	O fornecedor do PDV ou do ERP	A Visio, a partir do mapeamento das fontes
Por loja	Se o time construir	Depende do arquivo	Conforme o fornecedor	Sim, a loja é a unidade
Vários apps na mesma pergunta	Uma integração por app	Um arquivo por app	Só os apps que o fornecedor integra	Cada app é uma fonte, na mesma linha do tempo
Banco na mesma linha do tempo	Se o time construir	Manual	Conforme o fornecedor	Extrato por Open Finance, por loja
Definição por número	A do time	A de cada planilha	A do sistema	Uma, escrita uma vez pela Visio
Pergunta na sua IA	Se o time construir	Depende do que se faz com o arquivo	Só o que o sistema tem	Pelo MCP da Visio, com o seu login
Quem mantém	O time do grupo	A pessoa que baixa	O fornecedor	A Visio: nada para hospedar nem manter

Cenários: três situações de rede

Um app novo entra na operação. A rede passa a vender por mais um marketplace. Na camada, ele é mais uma fonte da classe delivery: pergunta-se ao app qual o caminho, o mapeamento registra, e a definição de taxa de delivery continua a mesma.

A regra de um app muda. Um app muda a documentação ou o formato do que entrega. O vínculo daquele app é revisto no mapeamento, e os demais são fontes separadas. A definição de cada número continua escrita uma vez.

Uma loja entra num app depois das outras. A fonte passa a trazer o dado dessa loja a partir de quando ela começou. Um número é tão honesto quanto a data em que a fonte começou a ser boa, e o mapeamento diz, fonte por fonte, desde quando o dado é bom.

Opinião do Head of Content

Lorenzo Lopez, Head of Content da Visio, observa que a pergunta por integrar «o delivery» pode ser uma pergunta por integrar vários apps ao mesmo tempo, e que um guia que trata de um só entrega metade da resposta. Para ele, o valor da página-mãe está em mostrar o que se repete em todos os apps, para que a página de cada um possa dizer só o que é dele.

A posição dele é a de que o grupo deve começar pela classe, com a mesma definição de receita líquida e de taxa para todos, e só depois abrir o caminho de cada app. Ele reconhece o mérito do que cada marketplace publica, do portal com homologação do iFood à referência pública da Rappi, e vê a camada de Dados do Visio OS como o lugar em que esses caminhos diferentes passam a responder a mesma pergunta.

Perguntas frequentes

Preciso de uma integração separada para cada app de delivery?

Cada app é uma fonte própria, porque cada um libera o dado do seu jeito. Para o grupo, isso não vira um projeto por app: o delivery é uma classe de fonte, e todos caem na mesma estrutura, por loja, com a mesma definição de cada número.

Os apps de delivery têm MCP?

Nas páginas consultadas em 12/10/2026, o iFood, a Rappi e o Aiqfome não publicam um MCP próprio. A sua IA lê o dado do delivery pelo MCP da Visio, depois que ele entrou na camada, com o seu login e só dentro das permissões.

Como somar delivery e balcão sem misturar os dois?

Os dois ficam separados na origem e são somados na pergunta, e não na exportação. Assim a soma e a comparação são possíveis sem perder a separação por canal.

E se o meu app não documenta API nem exportação?

Verifique com a Visio se já existe forma homologada ou parceiro integrador. A camada lê uma fonte por exportação ou relatório onde não há API e, quando nenhum dos dois serve, por um caminho de extração homologado. A Visio não extrai dado contra os termos de uso de um sistema.

O app que a minha rede usa não tem página aqui. Isso é um problema?

Não. O delivery é uma classe de fonte, e um app sem página entra pelo mesmo desenho: o mapeamento registra o caminho dele, e a definição de cada número continua a mesma. Verifique com a Visio se já existe forma homologada ou parceiro integrador para o seu caso.

Próximos passos

O próximo passo é o mapeamento de quais fontes a sua operação já tem e de como cada uma conecta, os apps de delivery entre elas.

Para ver a camada completa, leia a página da camada de Dados.

Ver também

Conclusão

Integrar os dados do delivery é tratar cada app como uma fonte por loja, percorrer o caminho que cada um documenta e entregar o resultado a uma camada que os estruture com uma definição por número, separados do balcão, ao lado do PDV e do banco. Cada fonte a mais é mais pergunta respondida na IA que você já usa.

Dados deixam tudo pronto pra usar. O Visio OS transforma em tarefa certa, pra pessoa certa.