Documentação

API

Endpoints REST para registros, buckets, arquivos e autenticação de usuários.

Base URL: https://api.rebun.dev/v1. Autentique com o header x-api-key: <chave>. Erros vêm como { error, message }.

curl https://api.rebun.dev/v1/tables/posts/records \
  -H "x-api-key: $REBUN_API_KEY"

Chaves e permissões

Cada rota exige uma permissão da chave (ex. record:read); sem ela, a resposta é MISSING_PERMISSION (403).

Chaves são de servidor por padrão: requisições com header Origin são recusadas com CLIENT_NOT_ALLOWED (403). Para usar no navegador, crie a chave com "Permitir uso no navegador"; o Origin precisa ser de um domínio autorizado do projeto.

Registros

Tabelas e colunas são criadas no painel; a API trabalha com os registros. Os valores vão e voltam como string | null; colunas jsonb vão e voltam como JSON (objeto, array, número, booleano, string ou null), e uma string enviada a elas é lida como texto JSON.

  • GET /tables/:name/records — lista. Devolve o array de registros no body e o total no header X-Total-Count. Query:

- select: JSON com os nomes das colunas (["name","age"]); sem ele, todas. Um caminho <fk>.<coluna> (["title","author.name"]) embute o registro referenciado ({ "title": ..., "author": { "name": ... } }), ou null se a referência estiver vazia ou o registro não puder ser lido; um nível, até 5 FKs. - where: JSON com uma condição ["coluna", "operador", "valor"] ou um grupo { "and": [...] } / { "or": [...] }, aninhável (até 5 grupos e 50 condições). Operadores: ==, !=, >, >=, <, <=, in e not in (valor é uma lista de até 100 itens), like e ilike (só colunas text); null só com ==/!=. Consulta inválida → INVALID_QUERY (422). - order: JSON com até 5 critérios ["coluna", "asc" | "desc"] ([["views","desc"],["title","asc"]]), em qualquer coluna; null fica no fim em asc e no começo em desc, e o id desempata. Sem ele, created_at desc. - skip: quantos pular (padrão 0); take: quantos trazer (padrão 20, máximo 100; acima disso, 422).

  • GET /tables/:name/records/:id — busca um registro.
  • POST /tables/:name/records — cria. Body: { "values": { "coluna": "valor" } }.
  • PATCH /tables/:name/records/:id — atualiza, com o mesmo body.
  • DELETE /tables/:name/records/:id — remove; RECORD_REFERENCED (409) se outro registro aponta para ele.

Cada operação segue a regra de acesso da tabela, definida no painel. A regra owner usa o usuário do header Authorization: Bearer <accessToken>.

Buckets e arquivos

  • GET /buckets e GET /buckets/:name — lista e busca.
  • POST /buckets — cria. Body: { "name", "public"?, "maxFileSize"?, "allowedMimeTypes"? }.
  • PATCH /buckets/:name — atualiza só os campos enviados; os omitidos ficam como estão (maxFileSize: null e allowedMimeTypes: [] limpam).
  • DELETE /buckets/:name — remove o bucket e os arquivos.
  • POST /buckets/:name/files/upload-url — devolve { url }; faça PUT dos bytes nela, com exatamente o size e o Content-Type = mimeType declarados (senão 403).
  • POST /buckets/:name/files — confirma o envio. Body: { "path" }.
  • GET /buckets/:name/files/:path — devolve uma url assinada para download.

Auth de usuários

O login usa PKCE e devolve um code que é trocado por um access token.

  1. POST /auth/otp/start envia um código e um magic link por e-mail, ou POST /auth/:provider/start devolve a URL do Google ou GitHub.
  2. POST /auth/otp/verify troca o código de 6 dígitos por { code, state }.
  3. POST /oauth/token troca o code por { accessToken, expiresIn, user }.
  4. GET /auth/me devolve o usuário do token; POST /oauth/revoke encerra a sessão.

Limites

Por minuto: 120 requisições por chave de API. Estourar responde RATE_LIMITED (429) com Retry-After. Estourar a cota do plano responde PLAN_LIMIT_REACHED (402).