Documentação
Primeiros passos
Escolha a autenticação certa, dê contexto seguro ao seu agente e faça a primeira chamada.
Este guia é o ponto de partida para quem vai criar uma aplicação nova do zero com a Nova API V1.0. Antes de gerar código, escolha o fluxo de acesso correto e leia o contrato de cada operação que será usada.
Sua aplicação já usa o API Legado?
Essa versão será removida em breve. Não trate a mudança apenas como uma troca de URL. Siga o guia Migrar do API Legado para inventariar rotas, substituir a autenticação, validar compatibilidade e planejar o corte.
Escolha o tipo de integração
| Cenário | Use | Credencial inicial | Guia |
|---|---|---|---|
| Automação de um restaurante, backend próprio ou protótipo privado | API key | tk_test_... ou tk_live_... criada no AI Builders | API Key |
| SaaS, app de parceiro ou produto instalado por vários restaurantes | OAuth Authorization Code + PKCE | Client ID público tk_app_... | Autenticação de apps para a Takeat Store |
| Interface Takeat usada por um restaurante já autenticado | Sessão do restaurante | Token emitido pelo login Takeat | Reutilize a sessão somente dentro da interface autenticada |
Regra prática
Comece com API key quando o próprio restaurante controla a integração. Use OAuth quando cada cliente precisa entrar com a Takeat e autorizar seu app sem compartilhar uma API key. Reutilize a sessão do restaurante somente em interfaces Takeat ou fluxos interativos próprios; integrações de backend não devem pedir senha nem copiar o token do painel.
As rotas de dados aceitam os dois tipos de Bearer. Tokens OAuth precisam do
escopo de cada operação. A sessão do restaurante não carrega esses escopos: o
restaurant_id assinado limita todas as leituras e alterações ao próprio
restaurante. Chaves tk_ continuam proibidas diretamente em /v1.
Fluxo recomendado para vibe coding
1. Dê somente documentação ao agente
Peça ao agente para ler /llms.txt, o guia de autenticação em
Markdown e os contratos .md das operações necessárias. Não envie uma
credencial real no prompt.
2. Gere a estrutura sem segredos
Solicite .env.example, validação de configuração, um cliente HTTP isolado,
tipos de resposta e tratamento explícito de 400, 401, 403 e 429.
3. Configure a credencial fora do chat
Guarde a API key, ou os tokens emitidos por uma instalação OAuth, no
backend: use um .env.local ignorado pelo Git durante o desenvolvimento e
um gerenciador de segredos na hospedagem. O agente deve usar somente nomes
de variáveis e valores fictícios.
4. Teste no ambiente correto
Mantenha portal, API e credenciais do mesmo ambiente. Com API Key, use
tk_test_..., poucos dados e chamadas controladas. Respeite os limites
exibidos no AI Builders; uma chave de restaurante começa com 10 requisições
por minuto e no máximo 500 por dia.
5. Revise antes de publicar
Procure segredos no diff e no histórico, confirme que tokens não chegam ao navegador e valide a resposta real contra o contrato documentado.
Primeira chamada com API key
Crie a chave no AI Builders, guarde-a em
TAKEAT_API_KEY e faça a troca no backend:
const tokenBody = new URLSearchParams({
grant_type: "api_key",
api_key: process.env.TAKEAT_API_KEY,
});
const tokenResponse = await fetch("https://public-api.takeat.app/oauth/token", {
method: "POST",
headers: { "Content-Type": "application/x-www-form-urlencoded" },
body: tokenBody,
});
if (!tokenResponse.ok) {
throw new Error(`Falha ao emitir token: ${tokenResponse.status}`);
}
const { access_token: accessToken } = await tokenResponse.json();
const menuResponse = await fetch(
"https://public-api.takeat.app/v1/menu?channel=delivery",
{ headers: { Authorization: `Bearer ${accessToken}` } },
);O exemplo é intencionalmente server-side. Não prefixe a variável com
NEXT_PUBLIC_, VITE_, PUBLIC_ ou qualquer convenção que a envie ao bundle
do navegador.
Segurança obrigatória
- Nunca cole API keys, access tokens, refresh tokens, códigos OAuth,
code_verifier, senhas ou headers de autorização em uma conversa com IA. - Nunca faça commit de
.env, dumps, coleções com valores preenchidos, screenshots ou logs que contenham credenciais. - Guarde API keys e refresh tokens somente no backend, criptografados em repouso quando persistidos, e restrinja o acesso por serviço.
- Mostre ao agente nomes de variáveis e valores fictícios, por exemplo
tk_test_EXEMPLO, nunca o segredo verdadeiro. - Remova ou mascare
Authorization,api_key,refresh_token,codeecode_verifierde logs e ferramentas de observabilidade. - Use o menor conjunto de escopos possível. Uma operação que só lê o cardápio
deve usar
menu:read, não todos os escopos disponíveis. - Em caso de vazamento, revogue a chave no AI Builders, substitua o segredo na hospedagem e revise Git, logs, builds e histórico do provedor de IA.
Escolha um prompt oficial
Existem pontos de partida diferentes para API Key, OAuth e API Legado. Use o
prompt geral quando a aplicação ainda será criada e a autenticação ainda não
foi decidida. Para um app da Takeat Store, use o prompt específico; se já
houver código consumindo webhook.takeat.app, use o prompt do guia de
migração.
Criar uma aplicação nova
Comece do zero, escolha entre API Key e OAuth e desenhe a integração a partir dos contratos atuais.
Especificar um app para a Takeat Store
Crie uma especificação nova ou atualize a existente para OAuth e Takeat Store, sem misturar o fluxo de API Key.
Migrar do API Legado
Mapeie o uso do API Legado, preserve contratos compatíveis e faça o corte sem misturar credenciais.
Prompt para uma aplicação nova
Criar uma aplicação nova do zero
Oi! Preciso da sua ajuda para criar do zero uma aplicação integrada à Nova API
V1.0 da Takeat.
Contexto rápido: a Takeat é a plataforma que o restaurante usa para operar o
cardápio, as comandas e os pedidos. Esta é uma aplicação nova: não existe uma
integração anterior para preservar e nenhum endpoint do API Legado deve ser
usado. Leia as instruções do repositório. Se já houver um projeto neste
workspace, examine sua arquitetura e convenções; caso esteja vazio, escolha
uma estrutura simples e adequada antes de criar arquivos.
Stack: React com Vite e TypeScript no frontend; Node.js com TypeScript no
backend. Mantenha a integração com a Takeat e os segredos somente no backend.
Utilize banco de dados somente quando houver necessidade concreta de
persistência. Não adicione banco, ORM ou infraestrutura por padrão. Para dados
temporários e cache, prefira memória quando adequado. Se precisar de banco,
explique brevemente a necessidade e escolha a solução mais simples compatível
com os requisitos de segurança e operação.
A documentação oficial foi preparada para agentes e está disponível aqui:
https://docs.takeat.app/llms.txt — índice das páginas e contratos.
https://public-api.takeat.app/mcp — MCP unificado com OAuth para documentação e dados autorizados.
Sem o MCP, consulte o índice e as páginas Markdown diretamente.
Leia primeiro Primeiros passos, Autenticação com API Key, API Key e tokens e
Autenticação de apps para a Takeat Store. Escolha API Key para uma integração de um restaurante;
use OAuth Authorization Code com PKCE para um produto instalado por restaurantes
diferentes. Use o contexto para decidir; pergunte se o público estiver indefinido
e isso bloquear a implementação. Explique brevemente a escolha antes de gerar código.
Localize o contrato Markdown completo de cada operação antes de implementá-la.
Trate esses documentos como fonte da verdade: não invente endpoints, campos,
escopos ou comportamentos. Sinalize lacunas ou documentação inacessível e
avance no que não depende delas.
O que a integração precisa fazer:
Primeiro: conectar o restaurante usando o fluxo de autenticação correto.
Emissão, troca e renovação de tokens devem ocorrer somente no backend, conforme
o contrato, com rotação atômica e sem renovações concorrentes por credencial
ou instalação. Quando aplicável, isole credenciais, tokens, cache e dados por
restaurante e instalação. Preserve o login da aplicação e proteja as rotas
da integração com suas permissões de acesso.
Segundo: carregar o cardápio de delivery, incluindo categorias, produtos,
preços e complementos que o contrato disponibilizar. Derive os tipos dos
contratos confirmados e separe o cliente HTTP da Takeat da camada que prepara
os dados para a interface. Inclua estados de carregamento, ausência de
resultados e erro.
Terceiro: consultar comandas dentro dos limites de data publicados. Confirme
parâmetros, formatos UTC, escopos, paginação e formato de resposta antes de
definir tipos ou regras de negócio.
Quarto: tratar 400, 401, 403 e 429 com mensagens compreensíveis. Considere como
referência inicial 10 requisições por minuto e no máximo 500 por dia para uma
chave criada pelo restaurante, confirmando os limites na documentação.
Implemente cache, timeouts, deduplicação de chamadas e tentativas limitadas com
backoff e jitter para falhas que admitam repetição. Respeite Retry-After quando
disponível e evite polling desnecessário ou loops de autenticação. Solicite
somente os escopos necessários às operações.
Quinto: alternar entre Teste e Produção somente por configuração validada,
sem mudanças no código. Uma chave de Teste não cria dados fictícios. Faça
validações conservadoras e somente leitura na API, além das operações de
autenticação necessárias. Não crie nem altere dados reais do restaurante.
Configuração da API Key e das variáveis de ambiente:
Na hora de configurar a integração, me oriente exatamente sobre onde colocar
a API Key e quaisquer variáveis necessárias. Não presuma que eu saiba fazer isso.
- Examine o código de configuração e os arquivos de exemplo para identificar
como o backend carrega variáveis, sem abrir arquivos que contenham segredos.
- Informe o caminho exato do arquivo local que devo editar ou a área de
variáveis de ambiente do serviço de hospedagem, conforme o projeto.
- Liste os nomes exatos das variáveis utilizadas, a função de cada uma e quais
são obrigatórias ou opcionais. Diferencie nomes escolhidos para a aplicação
de parâmetros exigidos pelo contrato da Takeat.
- Mostre um exemplo copiável somente com valores fictícios e variáveis
necessárias ao fluxo escolhido.
- Explique onde obter a API Key conforme a documentação oficial, sem inventar
caminhos de menus.
- Diga quais processos reiniciar e como verificar se a conexão funcionou.
- Oriente-me a inserir a chave diretamente no local indicado e apenas avisar
quando terminar. Nunca peça o valor no chat ou em uma captura de tela.
- Valide a configuração sem imprimir valores. Informe somente os nomes das
variáveis ausentes ou inválidas e o estado da conexão.
Segurança é inegociável:
- Não peça API Keys, tokens, códigos OAuth, code_verifier ou headers
Authorization no chat.
- Não abra, imprima nem altere arquivos .env que possam conter segredos.
A inserção de valores reais será feita por mim, seguindo suas orientações.
- Entre os arquivos de ambiente, crie ou atualize somente .env.example com
nomes e valores fictícios, preservando exemplos já existentes.
- A aplicação pode consumir configurações no backend em tempo de execução,
sem expor valores. API Keys e tokens da Takeat nunca devem chegar ao
navegador. Nunca coloque segredos em variáveis VITE_* ou no frontend.
- Não registre segredos, códigos OAuth, code_verifier ou Authorization em
logs, Git, mensagens de erro ou artefatos. Proteja credenciais e tokens
persistidos com criptografia em repouso e acesso restrito.
- Trate o código OAuth somente no redirecionamento necessário e no backend,
sem exibi-lo na interface nem persistir em logs.
- Verifique se arquivos locais de segredos estão protegidos contra inclusão
no Git, sem ler seu conteúdo.
Antes de implementar, apresente um resumo de no máximo cinco tópicos sobre
estrutura, pontos de integração, autenticação, cuidados essenciais e ordem de
execução. Cite as URLs Markdown efetivamente consultadas e diferencie recursos
confirmados de lacunas. Em seguida, implemente sem esperar aprovação do plano.
Execute as verificações essenciais disponíveis, incluindo compilação, checagem
de tipos e testes pertinentes às áreas modificadas. Verifique os fluxos
existentes afetados. Use fixtures fictícias para testes locais quando necessário,
mas não apresente resultados simulados como respostas reais da Takeat.
Não declare como testada uma integração sem validação com acesso real.
Ao terminar, mostre como acessar os recursos, o que foi alterado e verificado,
as instruções de configuração e qualquer pendência com a ação mínima para
resolvê-la. Registre os contratos consultados e a configuração na documentação
do projeto, sem duplicação desnecessária.
Orientações de colaboração:
O dono da aplicação é um vibe-coder e não é programador. Comunique-se em
português simples, com mensagens curtas e foco no que consigo ver e usar.
Assuma as decisões técnicas: não pergunte sobre bibliotecas, organização de
arquivos ou escolhas reversíveis que você pode resolver. Informe brevemente
as suposições relevantes e continue.
Minimize interrupções. Pergunte somente quando faltar informação indispensável
que não possa ser descoberta nem resolvida com uma suposição segura. Agrupe
as dúvidas e continue as partes independentes enquanto aguarda. Não peça
aprovação do plano nem pergunte “posso continuar?” entre etapas.
Você está autorizado a inspecionar o projeto, criar e editar arquivos da
aplicação, instalar dependências necessárias e executar verificações locais.
Preserve alterações preexistentes no workspace. Essa autorização não inclui
publicar a aplicação, contratar serviços, executar ações destrutivas ou
alterar dados reais do restaurante.
Prefira arquitetura simples, poucas dependências e componentes disponíveis.
Evite planos longos, comparações extensas de tecnologias, refatorações não
relacionadas e funcionalidades extras. Não pule contratos, segurança ou
verificações essenciais. Se faltar uma credencial, oriente sua configuração
e continue o trabalho independente, sem fingir que a conexão está funcionando.
Dê atualizações curtas sobre progresso relevante ou bloqueios. Se precisar
de uma ação minha, explique exatamente o que fazer, sem jargão e sem solicitar
segredos no chat.