Takeat
Versão da documentação
Começando

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árioUseCredencial inicialGuia
Automação de um restaurante, backend próprio ou protótipo privadoAPI keytk_test_... ou tk_live_... criada no AI BuildersAPI Key
SaaS, app de parceiro ou produto instalado por vários restaurantesOAuth Authorization Code + PKCEClient ID público tk_app_...Autenticação de apps para a Takeat Store
Interface Takeat usada por um restaurante já autenticadoSessão do restauranteToken emitido pelo login TakeatReutilize 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, code e code_verifier de 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.

Prompt para uma aplicação nova

Prompt pronto para usar

Criar uma aplicação nova do zero

Copie e adapte
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.
Revise o contexto antes de enviar e nunca inclua credenciais reais.

Continue daqui

On this page