Introdução
O que a API de Parceiros do BackResto expõe hoje, o que deliberadamente não expõe, e quem decide.
O BackResto é a aplicação de conformidade HACCP que as equipas de restauração preenchem durante o serviço: controlos de receção, temperaturas de confeção e de arrefecimento, planos de limpeza, etiquetas. A API de Parceiros entrega esse registo ao software que os seus clientes já utilizam: um ERP, um portal de fornecedores, um painel de qualidade, um assistente de IA.
É uma API HTTP só de leitura, com um esquema de autenticação e um formato de
erro, descrita de ponta a ponta por um
documento OpenAPI que pode carregar
diretamente num gerador de clientes ou numa definição de ferramenta para um
LLM. Os mesmos dados estão acessíveis por MCP em
https://api.backresto.com/mcp, com a mesma chave e as mesmas permissões, se o
que quer é fazer perguntas em vez de escrever um cliente.
O restaurante decide o que vê
Esta é a parte que vale a pena ler duas vezes, porque é diferente da maioria das APIs com que se vai integrar.
Não há inscrição. Uma chave é emitida manualmente, limitada a restaurantes nomeados e a scopes nomeados, e apenas depois de os restaurantes em questão terem concordado. Peça uma por email (Obter uma chave é a lista de verificação) e ela chega ao contacto técnico que indicar.
A consequência é firme: uma chave alcança os restaurantes que lhe foram
concedidos e mais nada. O restaurant-3 não aparece só porque o
restaurant-1 e o restaurant-2 estão na mesma chave, e nenhum pedido que
possa fazer alarga isso. Acrescentar um estabelecimento é outra conversa, com
as pessoas a quem os dados pertencem.
A vantagem de um pequeno passo manual é que a revogação é igualmente direta: um email e a chave está morta no pedido seguinte.
O que está nos dados
| Recurso | O que é |
|---|---|
| Entregas | Duas coleções: um registo por controlo de receção (fornecedor, veredito de conformidade, motivos de não conformidade, ações corretivas, comentário livre, uma leitura de temperatura por produto, sempre em graus Celsius), e as fotografias tiradas na receção. |
| Coleções e registos | Mais vinte e quatro tipos de registo, que partilham um único envelope e estão documentados por domínio: temperaturas, arrefecimento e processos alimentares, limpeza, fritadeiras, análises de superfície, etiquetas de rastreabilidade, documentos, catálogo e as instalações e pessoas por trás deles. |
Tudo isto é só de leitura. Nada que uma chave de parceiro possa chamar escreve nos registos de um restaurante: a aplicação é onde os dados de conformidade são criados, pela pessoa que responde por eles.
O que ainda não está aqui
Ser explícito quanto aos limites poupa-lhe uma tarde:
- Sem recuperação de histórico. Os registos de um restaurante tornam-se visíveis para esta API a partir do momento em que a captura é ativada para esse restaurante. O que veio antes está na aplicação, não aqui, exceto no caso das entregas, que trazem o histórico que a aplicação ainda tinha. Não trate um percurso vazio como prova de que nada aconteceu. Veja Suporte.
- Sem escritas, sem webhooks. Cabe-lhe a si consultar. Se precisa de receber notificações, diga-nos; é uma questão de procura, não de princípio.
- Sem cursor incremental nas coleções. Atualizar uma coleção significa
voltar a percorrê-la e reconciliar pelo
id. - Sem início de sessão com uma conta BackResto. A chave de parceiro continua a ser a credencial. Os clientes MCP que só pedem um URL, como Claude e ChatGPT, podem ligar-se por OAuth: abre-se uma página BackResto onde cola a chave. As permissões continuam a ser as dessa chave.
URL de base
| Ambiente | Origem |
|---|---|
| Produção | https://api.backresto.com |
| Pré-produção | https://api-preprod.backresto.com |
| Desenvolvimento | https://api-dev.backresto.com |
Uma chave é criada num ambiente e não significa nada nos outros: as chaves, as concessões e os dados são por ambiente. Tudo o que se segue usa a origem de produção.
Pronto? Faça a sua primeira chamada.