Integração de API para restaurante é a automação que faz um sistema avisar o outro quando algo muda, sem alguém digitar de novo a mesma informação duas vezes. O pedido chega no aplicativo de delivery e já nasce como tarefa na cozinha. A venda fecha no PDV e o estoque desconta o insumo sozinho. Um sensor de temperatura sai da faixa segura e o responsável do turno recebe o aviso antes do cliente sentir o problema. É esse tipo de conexão, concreta e rastreável, que separa a operação que ainda depende de planilha da que roda com dado atualizado em tempo real.
Antes de escolher o que integrar primeiro, ajuda entender onde isso se encaixa na pilha de tecnologia do restaurante. Quem ainda está decidindo entre PDV, ERP e checklist deveria começar pela comparação entre os tipos de software de gestão para restaurante, porque cada categoria resolve um problema diferente. Este texto assume que essa escolha já foi feita e explica o que acontece quando esses sistemas trocam dados entre si dentro do Koncluí.
Como um pedido de delivery vira tarefa na cozinha sem digitação manual
Quando o iFood ou o Rappi confirmam um pedido, a plataforma de delivery dispara um evento. Uma integração lê esse evento e chama a API de checklists do Koncluí para criar a tarefa correspondente, com o horário de entrada registrado. Não existe planilha intermediária nem alguém copiando o número do pedido para outro sistema.
Vale ser direto sobre um ponto que costuma gerar frustração: essa ponte não é um botão de ligar. Ela é construída em cima das APIs que cada lado publica, e por isso a primeira pergunta de qualquer projeto de integração é se os dois sistemas expõem os endpoints necessários e sob quais condições de acesso.
O mesmo raciocínio vale para o PDV, com uma diferença importante de escopo. Uma venda fechada no caixa gera um evento de baixa de estoque, e quem executa essa baixa é o sistema de estoque ou o ERP, não o checklist. Sem integração, esse ajuste depende de alguém lançar manualmente ao fim do turno, o que atrasa a informação e abre espaço para erro de digitação. Com a conexão de pé, o estoque reflete o consumo real minutos depois da venda, não no dia seguinte.
Os eventos que já circulam entre PDV, delivery e checklist
Cada sistema conectado gera um tipo específico de evento, e cada evento aciona uma ação diferente dentro da operação. A tabela abaixo ajuda a mapear o que priorizar primeiro, de acordo com o que já causa mais retrabalho na sua casa:
| Sistema conectado | Evento que dispara a integração | O que a automação dispara, e em qual sistema |
|---|---|---|
| iFood, Rappi e outras plataformas de delivery | Pedido confirmado ou cancelado | Cria ou encerra a tarefa de preparo no checklist, com horário de entrada |
| PDV (Totvs, Linx e similares) | Venda fechada no caixa | Baixa o insumo da ficha técnica no sistema de estoque ou no ERP |
| Sensor de temperatura de câmara ou freezer | Leitura fora da faixa configurada | Registra a leitura como não conformidade no checklist e notifica o responsável do turno |
| Sistema de estoque e compras | Insumo atinge o nível mínimo | Dispara alerta de reposição para quem compra, no próprio sistema de compras |
| Financeiro e emissão de notas | Fechamento de caixa do turno | Concilia a venda registrada com a nota emitida, no sistema financeiro |
Repare que só duas dessas linhas terminam dentro do checklist: a tarefa de preparo e a não conformidade de temperatura. Baixa de estoque, reposição e conciliação fiscal acontecem no sistema que já é dono desse dado, e o checklist entra depois, como conferência do que foi feito. Confundir as duas pontas é o que faz gestor comprar um sistema esperando que ele resolva o inventário sozinho.
Nem toda casa precisa das cinco integrações ao mesmo tempo. A escolha certa é começar pelo evento que hoje gera mais retrabalho manual ou mais erro de digitação, não pela lista inteira de uma vez.
Integrar sistemas e integrar via API não são a mesma decisão
Vale separar dois assuntos que costumam ser tratados como sinônimo. Decidir quais sistemas conversar entre si (PDV com estoque, delivery com financeiro) é uma decisão de arquitetura, discutida com mais profundidade no texto sobre integração entre os sistemas do restaurante. Já o mecanismo técnico que faz essa conversa acontecer, geralmente via API e webhook, tem um panorama mais amplo no texto sobre integração de APIs para restaurante, que cobre o cenário além do Koncluí.
Este texto fica no meio dos dois: assume que a decisão de arquitetura já existe e explica como a conexão funciona especificamente dentro do Koncluí, na prática do dia a dia.
O que uma integração de API exige em termos de segurança de acesso
Toda integração via API deveria seguir o mesmo princípio que a especificação OAuth 2.0, publicada pela IETF, resolveu para a web: um sistema terceiro recebe um token de acesso com escopo e prazo limitados, em vez de guardar a senha do outro sistema em texto puro. Isso significa, na prática, três coisas para o gestor de restaurante que está configurando uma integração:
- Cada chave de acesso deve ter a permissão mínima necessária, nunca acesso total à conta.
- Tokens têm validade e devem ser revistos periodicamente, não configurados uma vez e esquecidos.
- O tráfego entre sistemas deve ser criptografado (TLS), o mesmo padrão usado por qualquer transação bancária online.
Existe também a camada de dados pessoais. Quando a integração envolve informação de cliente, como nome, telefone ou endereço de entrega vindos do delivery, o compartilhamento entre empresas passa a ser regulado pela Lei 13.709/2018, a Lei Geral de Proteção de Dados, que alcança o tratamento de dados pessoais inclusive nos meios digitais e é fiscalizada pela Autoridade Nacional de Proteção de Dados. Na prática, isso significa ter clareza contratual sobre quem é responsável pelo dado em cada ponta da integração, e não tratar o compartilhamento como um detalhe técnico invisível.
Colocar a primeira integração de pé sem travar o caixa
A sequência que funciona é pequena e sequencial, não um projeto de meses:
- Mapear o processo que mais dói. Escolha um só: pedido de delivery, baixa de estoque ou controle de temperatura. Não tente integrar tudo na primeira semana.
- Identificar o sistema de origem do dado. Confirme se o PDV ou a plataforma de delivery já expõe uma API de parceiro, e se ela exige cadastro prévio.
- Testar fora do horário de pico. Simule o evento em horário de baixa movimentação e confira se a tarefa criada no Koncluí bate com o pedido de origem.
- Rodar em paralelo por alguns dias. Mantenha o processo manual como conferência até confirmar que a integração está estável.
- Só então desligar o processo manual daquele ponto específico, e seguir para o próximo evento da lista.
Esse roteiro reduz o risco do erro mais comum: integrar tudo de uma vez, sem período de validação, e descobrir o problema só quando o caixa já fechou errado.
Por que o registro gerado pela integração precisa ser rastreável
Uma tarefa criada automaticamente por um evento de API só tem valor se o registro dela for confiável depois, com data, hora e responsável identificáveis. Existe um parâmetro público útil aqui, ainda que ele trate de outro caso. O art. 4º do Decreto federal 10.278/2020, que fixa a técnica e os requisitos para a digitalização de documentos físicos, exige cinco coisas do processo: integridade e confiabilidade, rastreabilidade e auditabilidade, padrões técnicos que garantam a legibilidade, confidencialidade quando aplicável, e interoperabilidade entre sistemas informatizados. Esse decreto não regula o registro que já nasce digital, como o checklist criado por um evento de API, mas a lista funciona como régua de exigência: um registro que atende os cinco pontos é mais defensável diante de uma fiscalização do que uma anotação solta em caderno.
É essa mesma lógica de rastreabilidade que sustenta os benefícios do checklist digital frente ao papel: o registro automático não depende da memória de quem estava de plantão no fim do turno.
O que a integração não resolve sozinha
Conectar sistemas não conserta um processo mal desenhado. Se o item do checklist está escrito de forma vaga, ele continua vago depois de virar um evento automático, só que mais rápido. O ganho real da integração aparece quando o procedimento por trás já estava certo antes de qualquer API entrar em cena.
Ela também não substitui a leitura humana dos dados. Uma integração gera eventos, mas é o dashboard operacional do restaurante que transforma esse volume de eventos em decisão: qual item falha sempre, qual turno atrasa mais, qual unidade precisa de atenção esta semana. Sem esse passo, a integração só troca o caderno de papel por um caderno digital que ninguém lê.
Se você já usa o aplicativo de checklists do Koncluí e quer partir de um modelo pronto em vez de escrever cada rotina do zero, a biblioteca de checklists do Koncluí tem modelos por tipo de negócio que servem de ponto de partida antes de conectar qualquer evento automático a eles.
O que ainda fica em aberto na hora de ligar a primeira API
E se o iFood, o Rappi ou o PDV caírem no meio do serviço?
A integração para de receber eventos enquanto o sistema de origem estiver fora. O pedido ou a venda não somem, mas a tarefa automática deixa de nascer até a conexão voltar. Por isso o processo manual de backup, o mesmo que você usou na fase de teste em paralelo, precisa continuar documentado e acessível no turno, não só na pasta de implantação. Quando a API retorna, confira se os eventos do intervalo foram reprocessados ou se alguém precisa registrar o que ficou no meio.
Minha rede tem duas unidades com CNPJ diferente. Preciso de duas integrações?
Na prática, sim: cada unidade com CNPJ próprio costuma ser uma conta ou um ambiente de acesso separado no PDV, no delivery e no checklist. A mesma chave de API de uma loja não deve servir para a outra, porque mistura pedidos, estoque e responsáveis de turno. Mapeie cada CNPJ como um fluxo completo, com tokens e permissões próprios, mesmo que o procedimento de cozinha seja idêntico nas duas casas.
Meu PDV não tem API de parceiro. Ainda dá para automatizar alguma coisa?
Sem endpoint público, a baixa automática de estoque a partir do caixa geralmente não sai do papel. Nesse caso, o caminho realista é priorizar o que já expõe API: delivery, sensor de temperatura ou o próprio checklist com registro no celular. Forçar planilha intermediária ou exportação manual diária não é integração via API: é o retrabalho que você estava tentando eliminar, só com um passo a mais.
Se a integração criar tarefa errada, quem responde na fiscalização?
A responsabilidade sanitária e operacional continua com o estabelecimento, não com o fornecedor do software. A API só transporta o evento; quem define o procedimento, o responsável do turno e a correção da não conformidade é a casa. Se um evento nascer com item errado ou horário inconsistente, o gestor precisa de trilha para corrigir e justificar o registro, não de esperar que a integração “se explique” sozinha diante da vigilância.
Depois de ligar a automação, a equipe ainda anota no papel por precaução. Isso atrapalha?
Por alguns dias, anotar em paralelo é o método certo de validação. Depois que a integração se mostra estável, manter os dois canais vira fonte de divergência: um registro diz uma coisa e o outro diz outra, e na hora da auditoria ninguém sabe qual é o oficial. Escolha uma data para desligar o papel daquele fluxo específico e comunique o turno com clareza sobre qual sistema passa a ser a fonte de verdade.
Quando o evento chega sozinho e a equipe só confere
Quem aplica o roteiro deste texto troca digitação em dobro por conferência pontual: o pedido, a venda ou o alerta de temperatura já chegam com horário e origem, e o turno valida em vez de recriar a informação. O ganho aparece no dia a dia, no caixa e na fiscalização, quando o registro deixa de depender da memória de quem fechou o turno. Se ainda falta o modelo de checklist por trás da automação, comece pelos modelos prontos da biblioteca de checklists do Koncluí e só depois conecte o primeiro evento.