Integração de APIs para restaurante é a conexão automática entre dois ou mais sistemas, PDV, delivery, estoque, ERP ou pagamento, que troca dados sozinha, sem alguém digitar a mesma informação duas vezes. Um pedido confirmado no aplicativo de delivery vira tarefa na cozinha e baixa de estoque no mesmo instante. Uma venda fechada no caixa atualiza o financeiro sem planilha intermediária. É uma decisão de arquitetura técnica, não um recurso que se liga com um clique, e por isso vale entender o mecanismo antes de contratar qualquer fornecedor.
Antes de ir direto ao “como”, ajuda situar essa decisão dentro do quadro maior. Quem ainda está escolhendo entre PDV, ERP e sistema de checklist deveria começar pelo comparativo entre os tipos de software de gestão para restaurante, porque cada categoria resolve um problema diferente e a integração só faz sentido depois que essa escolha está feita.
O que muda quando os sistemas trocam dados por API em vez de planilha
Uma API, sigla de Application Programming Interface, é um contrato técnico que permite que um sistema peça ou envie dados a outro de forma estruturada, geralmente por uma requisição HTTP que devolve uma resposta em formato JSON. No fluxo de delivery, isso costuma acontecer por webhook: o sistema de origem (o app de delivery, por exemplo) avisa automaticamente o sistema de destino assim que um evento acontece, sem que ninguém precise ficar consultando o sistema de origem a cada minuto.
A diferença prática aparece no que cada modelo exige da equipe. No fluxo manual, alguém confere o pedido no tablet do delivery, digita o item no PDV, ajusta o estoque no fim do turno e concilia o financeiro no dia seguinte. Cada etapa manual é um ponto onde um número pode ser digitado errado ou simplesmente esquecido. No fluxo integrado, o evento dispara a cadeia inteira sozinho: o pedido nasce no PDV, o insumo é descontado do estoque e a cozinha recebe a tarefa, tudo no mesmo minuto em que o cliente confirmou a compra.
Isso não elimina o trabalho de decisão, só remove a digitação repetida. Alguém ainda precisa olhar o relatório de CMV, decidir o que comprar e treinar a equipe. A integração troca o tempo gasto em lançamento manual por tempo disponível para essas decisões.
Os pontos de integração mais comuns na operação de um restaurante
Nem todo restaurante precisa conectar tudo de uma vez. A tabela abaixo mapeia as conexões mais frequentes, o mecanismo técnico por trás de cada uma e o que efetivamente é sincronizado, para ajudar a priorizar por onde começar:
| Sistemas conectados | Mecanismo técnico mais comum | O que é sincronizado |
|---|---|---|
| Plataforma de delivery (iFood, Rappi) e PDV | Webhook de pedido confirmado | Criação automática do pedido no PDV, com itens e valor já lançados |
| PDV e sistema de estoque ou ERP | API REST acionada pelo fechamento da venda | Baixa do insumo conforme a ficha técnica de cada prato vendido |
| Maquininha de cartão ou Pix e PDV | API de conciliação de pagamento | Confirmação de que o valor recebido bate com a comanda |
| PDV e emissor de documento fiscal (NFC-e ou modelo exigido no estado) | Webservice de transmissão à SEFAZ | Emissão automática do documento fiscal no fechamento da venda |
| Sensor de temperatura (IoT) e sistema de checklist | API de eventos com limiar configurado | Registro de não conformidade quando a leitura sai da faixa segura |
Repare que cada linha termina num sistema diferente. A integração não centraliza tudo num único painel por si só, ela move o dado certo para o sistema que já é responsável por aquele processo. Quem decide o que priorizar deveria olhar primeiro para o processo que hoje gera mais retrabalho manual, não para a lista inteira de conexões possíveis.
Autenticação e permissões que toda integração de API deveria exigir
Conectar dois sistemas significa dar a um deles acesso a dados do outro, o que torna a segurança dessa conexão um requisito, não um detalhe opcional. A referência técnica mais citada para esse tipo de acesso é a especificação OAuth 2.0 da IETF (RFC 6749): em vez de um sistema guardar a senha do outro, o sistema autorizado recebe um token de acesso com escopo e validade limitados. Na operação, o fornecedor ainda precisa permitir revogar ou rotacionar esse token sem trocar a senha da conta principal em toda a cadeia; isso é boa prática de segurança, e o protocolo de revogação de tokens da IETF é a RFC 7009, não a 6749.
Na prática, isso se traduz em três exigências que qualquer gestor deveria cobrar do fornecedor antes de autorizar uma integração:
- Cada chave de acesso tem permissão mínima necessária, nunca acesso total à conta do sistema de origem.
- O token tem prazo de validade e pode ser revogado ou substituído sem afetar as demais integrações ativas.
- O tráfego entre os sistemas usa TLS (criptografia em trânsito), o mesmo tipo de proteção usado em transações financeiras online.
Dados de cliente cruzando sistemas: o que muda quando entra a LGPD
Boa parte das integrações de restaurante carrega dado pessoal. O app de delivery repassa nome, telefone e endereço de entrega do cliente para o PDV ou para uma ferramenta de fidelidade. Esse tratamento e o compartilhamento entre empresas diferentes são regulados pela Lei 13.709/2018, a Lei Geral de Proteção de Dados, cuja fiscalização cabe à Autoridade Nacional de Proteção de Dados (ANPD).
Isso não é um obstáculo burocrático a ser ignorado até dar problema. Na prática, exige que o contrato entre o restaurante e cada fornecedor deixe claro quem é controlador ou operador do dado em cada ponta da integração e por quanto tempo ele fica armazenado depois que o pedido é concluído. Um fornecedor de API que não sabe responder essa pergunta é um sinal de alerta, não um detalhe técnico a resolver depois.
Como colocar a primeira integração de pé sem parar o caixa
O roteiro que funciona é curto e sequencial, não um projeto de meses fechado antes de qualquer teste real:
- Escolha um único processo para começar. Pedido de delivery, baixa de estoque ou emissão fiscal, não os três ao mesmo tempo.
- Confirme que os dois sistemas expõem a API necessária. Nem todo PDV publica endpoint aberto para terceiros, e isso muda o fornecedor a escolher.
- Teste fora do horário de pico. Simule o evento num momento de baixa demanda e confira se o resultado no sistema de destino bate com a origem.
- Rode em paralelo por alguns dias. Mantenha o processo manual como conferência até a integração se mostrar estável.
- Só então desligue o processo manual daquele ponto e siga para a próxima conexão da lista.
Esse roteiro existe para evitar o erro mais caro do processo: integrar tudo de uma vez, sem período de validação, e descobrir a falha só quando o caixa já fechou errado.
Onde projetos de integração costumam travar
Três causas aparecem com frequência quando o projeto emperra. A primeira é incompatibilidade real entre sistemas: um fornecedor que promete API mas na verdade oferece só exportação manual de planilha. A segunda é resistência da equipe, que passa a desconfiar de um sistema que “faz sozinho” o que ela sempre fez manualmente, e isso se resolve com treinamento simples, não com mais tecnologia. A terceira é ausência de sandbox: testar direto em produção sem ambiente de simulação transforma qualquer erro de configuração em problema real no caixa do restaurante.
Nenhuma dessas três se resolve comprando mais integração. Elas se resolvem com cronograma realista, um processo por vez e envolvimento de quem vai operar o sistema no dia a dia desde o início do projeto.
O que a integração de APIs não resolve sozinha
Conectar sistemas não conserta um processo mal desenhado, só o executa mais rápido. Se a ficha técnica está incompleta ou o item do checklist está escrito de forma vaga, ele continua incompleto e vago depois de virar um evento automático. O ganho real da integração aparece quando o procedimento por trás já estava certo antes de qualquer API entrar em cena.
Vale separar também duas decisões que parecem a mesma coisa mas não são. Decidir quais sistemas devem conversar entre si, se o PDV precisa falar com o estoque ou se o delivery precisa falar com o financeiro, é uma decisão de arquitetura entre os sistemas do restaurante, discutida à parte. O mecanismo técnico que faz essa conversa acontecer é o assunto deste texto. E depois que os eventos estão fluindo, ainda falta o passo que transforma volume de dados em decisão: um dashboard operacional que mostra qual item falha com mais frequência e qual turno atrasa mais. Sem esse passo, a integração só troca o caderno de papel por um caderno digital que ninguém lê, o mesmo motivo pelo qual os benefícios do checklist digital dependem de rastreabilidade, não só de automação.
Se você quer ver como esse mecanismo de integração é descrito dentro de um produto específico de checklists, o texto sobre integração de APIs no Koncluí detalha os eventos previstos entre PDV, delivery e checklist. E se o caminho seguinte for padronizar as rotinas antes de automatizá-las, a biblioteca de checklists prontos por tipo de negócio é um ponto de partida melhor do que escrever cada procedimento do zero.
Dúvidas que aparecem depois que a primeira API sobe
E se a API do delivery cair no horário de pico?
Trate a integração como caminho principal, não como único caminho. Antes do go-live, defina com a equipe o procedimento de contingência: quem confere o tablet do app, quem lança no PDV e até quando o manual fica ativo. No contrato com o fornecedor, peça tempo máximo de restabelecimento e canal de status em horário comercial e em fim de semana. Sem esse plano, a queda vira fila na cozinha e comanda sem baixa de estoque.
Quem responde se o pedido entrou no app e não chegou no PDV?
A responsabilidade precisa estar escrita antes do primeiro pedido real. Em geral, o restaurante é dono do processo e cada fornecedor responde pela ponta dele: o app pelo envio do webhook, o PDV pelo recebimento e gravação. No contrato, deixe claro o prazo de abertura de chamado, o log que cada lado deve guardar e quem aciona o suporte quando o cliente reclama de atraso. Sem isso, o problema vira troca de culpa enquanto o prato esfria.
Duas unidades com CNPJ diferente usam a mesma chave de API?
Quase nunca. Cada CNPJ costuma ser uma conta fiscal, um cadastro no delivery e um conjunto de permissões separado. A integração precisa de token, escopo e fila de eventos por unidade, senão pedido, estoque e NFC-e se misturam entre lojas. Se o grupo quer um painel único, isso é consolidação de relatório depois da sincronização, não um único login compartilhado no caixa.
Depois de pagar a implantação, ainda existe taxa recorrente de API?
Pergunte isso por escrito antes de autorizar o token. Alguns fornecedores embutem a integração na mensalidade do PDV ou do delivery; outros cobram por pedido sincronizado, por volume de chamadas ou por conector adicional. Inclua também quem paga a manutenção quando o app muda a versão da API e quebra o fluxo. Surpresa de custo costuma aparecer no segundo ou terceiro mês, não no dia da demonstração.
A equipe continua digitando o pedido no PDV mesmo com a integração ligada. O que fazer?
Isso gera pedido duplicado, estoque negativo e comanda fiscal errada. Nos primeiros dias, compare pedido a pedido o que chegou pelo webhook e o que a equipe lançou à mão, e mostre o retrabalho no fechamento do turno. Ajuste o treinamento com um único caminho oficial: se o pedido veio do app, ninguém recria no caixa. Se a digitação manual continuar, a falha é de hábito e de supervisão, não de falta de tecnologia.
Quando o dado passa a circular sem digitar de novo
Quem aplica o roteiro deste texto troca lançamento repetido por conferência e decisão: um processo por vez, em paralelo com o manual, até a equipe confiar no fluxo automático. A operação deixa de depender de alguém lembrar de copiar o pedido ou baixar o estoque no fim do turno. Se a próxima etapa for padronizar as rotinas que a API ainda não toca, a biblioteca de checklists prontos por tipo de negócio ajuda a deixar o procedimento claro antes de automatizar o restante.