Publicar na Takeat Store

A Takeat Store reúne aplicativos que um restaurante pode conhecer e conectar à própria conta. Cada app aprovado recebe um Client ID público e usa OAuth Authorization Code com PKCE; nenhum restaurante precisa compartilhar API key, senha ou sessão com o desenvolvedor.

Store e API Key são jornadas diferentes

Uma API key pertence ao restaurante que a criou e atende automações próprias. Um app da Store pertence ao desenvolvedor e pode ser instalado, com consentimento independente, por vários restaurantes. Os dois fluxos terminam em um access token Bearer para as rotas /v1, mas criação, renovação, revogação e responsabilidade pelas credenciais continuam separados.

Quando publicar um app

Use a Store quando seu produto:

será conectado por restaurantes de empresas diferentes;
precisa mostrar uma tela de consentimento com identidade e permissões claras;
deve manter tokens, cache e jobs isolados por instalação;
oferece um site ou painel próprio para o restaurante usar depois da conexão.

Para um script, ERP interno ou automação controlada por um único restaurante, use Autenticação com API Key. Não crie um app para a Takeat Store apenas para ocultar uma API key no navegador: segredos e tokens continuam sendo responsabilidade do backend.

Ciclo de publicação

Prepare a especificação

Defina a proposta de valor, os fluxos do usuário, o modelo de preço, o suporte, os callbacks exatos e somente os escopos necessários. Use os prompts para agentes para criar ou atualizar essa especificação a partir do seu projeto.

Envie a proposta no AI Builders

Entre em AI Builders, acesse a área de apps para a Takeat Store e selecione Enviar novo app. A proposta fica vinculada ao restaurante autenticado e pode ser acompanhada pelos usuários dele.

Aguarde a análise da Takeat

Enviar a proposta não cria um Client ID, não publica o app e não autoriza restaurantes. Em caso de rejeição, revise a observação e envie uma nova proposta corrigida.

Implemente e teste OAuth

Depois da aprovação, copie o Client ID e a configuração do app. No Laboratório OAuth, valide o callback e a instalação, gere PKCE, troque um code, renove e revogue tokens e teste as rotas /v1 permitidas.

Publique e acompanhe instalações

O restaurante encontra o app na Store, revisa as permissões e autoriza a conexão. Seu backend passa a cuidar da instalação e do refresh token rotativo. A Takeat não executa a cobrança do seu produto.

O que preparar para a proposta

Grupo	Informação
Identidade	Nome do app, desenvolvedor ou empresa, logo e descrição curta
Contato	E-mail e telefone de suporte
Confiança	Site público e política de privacidade
Apresentação	README em Markdown e até 10 URLs de capturas de tela
Comercial	Gratuito, pagamento único, assinatura ou preço inicial; valor e período quando aplicáveis
OAuth	Ambiente, uma ou mais redirect URIs exatas e escopos mínimos

O logo é obrigatório para uma proposta nova. A descrição, o README e as capturas podem ser ajustados para explicar o produto com clareza, mas não substituem um site e uma política de privacidade válidos. URLs de produção usam HTTPS sem credenciais ou fragmentos. Em ambiente de teste, HTTP é aceito apenas para loopback, como localhost.

Todos os modelos publicados oferecem sete dias de teste. Essa é uma condição comercial que o desenvolvedor deve cumprir; a Takeat Store não cria assinaturas, processa pagamentos nem aplica automaticamente o período.

Identidade, instalação e visibilidade

Estes conceitos não são equivalentes:

Conceito	Significado
Proposta	Registro de autoria e análise enviado pelo restaurante desenvolvedor
App aprovado	Cliente OAuth público com Client ID, callbacks, escopos e ambiente
Publicação	Visibilidade do app no catálogo da Store
Instalação	Consentimento de um restaurante específico para um app específico

Um app oculto pode continuar acessível a instalações existentes, mas não aparece na descoberta pública. Suspender o app ou seu parceiro impede novas autorizações e renovações. Alterar escopos invalida consentimentos e tokens existentes; cada restaurante precisa revisar a nova lista e reconectar.

Checklist antes de enviar

O site explica o que o app faz e como obter suporte.
A política de privacidade descreve os dados acessados e sua retenção.
Cada callback pertence ao ambiente correto e coincide exatamente com a implementação.
O app não possui nem espera um client_secret.
Os escopos correspondem a funcionalidades visíveis na proposta.
Tokens e verifier ficam somente no backend do app.
Cada instalação tem armazenamento, lock de refresh, cache e jobs próprios.
A desconexão revoga tokens e interrompe tarefas futuras.
Testes cobrem aprovação, recusa, state divergente, code expirado, refresh rotativo, 401, 403 e 429.

Depois da aprovação

Use Ver configuração no AI Builders para copiar os endpoints e callbacks. Use Testar OAuth para executar o fluxo real sem misturá-lo ao testador de API Key. O laboratório nunca cria consentimento por conta própria: ele abre o portal oficial, e o proprietário ainda precisa entrar, revisar e decidir.

O laboratório não é a arquitetura do seu app

Para viabilizar o diagnóstico, essa ferramenta mantém code, verifier e tokens temporariamente na memória da aba autenticada. Ela não persiste nem exibe os tokens completos. Em produção, seu aplicativo deve validar o callback, trocar o code e armazenar os tokens exclusivamente no backend.

O teste pode acessar dados reais do restaurante. Ambiente test identifica a credencial e permite callbacks locais; ele não cria um banco sandbox. Prefira leituras, use IDs controlados e revise qualquer escrita antes de enviá-la.

Continue daqui

Aplicativos para garçons

Escolha Garçom no cadastro do aplicativo para usar autorização OAuth pessoal com PKCE. O perfil do Client ID é fixo e tem cinco permissões de leitura, distintas das permissões de restaurante. As oito consultas públicas apoiam o atendimento presencial, sem alterações de pedidos, pagamentos ou configurações. A conta e a loja vêm do token; não envie restaurant_id. Consulte o guia de aplicativos para garçons e a referência separada por perfil.

On this page