API do Supabase: o que dá para fazer e como usar com agentes de IA
O Supabase é uma plataforma de backend sobre Postgres que gera automaticamente uma API REST para as tabelas, além de oferecer autenticação, armazenamento de arquivos e funções. É usado por times de produto e desenvolvedores que constroem aplicações. O acesso é por chaves do projeto, com regras de segurança por linha (RLS).
Os grandes recursos da API, em português claro.
Consulta e escrita nas tabelas do Postgres por REST, respeitando as políticas de segurança.
Cadastro, login e gestão de usuários da aplicação.
Armazenamento e entrega de arquivos em buckets.
Funções executadas sob demanda, chamadas por HTTP.
Assinatura de mudanças nas tabelas em tempo real.
Administração de projetos da organização.
Como se acessa a API do Supabase.
- Com credencial da sua empresaUsa as chaves do projeto: a chave pública respeita as políticas de segurança por linha, e a chave de serviço ignora essas políticas e deve ficar restrita ao servidor.
- Documentação oficialsupabase.com/docs
- A chave de serviço ignora as políticas de segurança: não use para o agente sem necessidade.
- Exponha visões com só as colunas necessárias, sem dados pessoais desnecessários.
- Planos têm limites de uso e de requisições.
- api supabase
- supabase rest api
- supabase api documentação
- supabase api key
- supabase edge functions
- integração supabase
- supabase realtime
O que um agente do iTeam faz com a API do Supabase.
O gestor pergunta quantos usuários ativaram certa função na semana e o agente consulta as tabelas liberadas e responde com o número.
O agente de suporte consulta o cadastro e o status da conta do cliente na base para responder sem pedir ao time técnico.
Ajustes pontuais, como reativar uma conta, são preparados pelo agente e executados após aprovação.
O agente acompanha tabelas de pedidos ou erros e avisa quando o volume foge do normal.
Da credencial ao agente trabalhando, com aprovação.
Crie um papel e políticas para o agente
No Supabase, defina um papel ou uma visão com as tabelas e colunas que o agente pode ler, com políticas de segurança por linha.
Cadastre a chave no cofre
A chave fica no cofre do iTeam; evite a chave de serviço e libere escrita só onde for necessário.
Teste em projeto de desenvolvimento
Valide consultas em um projeto de teste e mantenha aprovação para qualquer alteração em produção.
Dúvidas sobre a API do Supabase.
A API do Supabase é gratuita?
O Supabase tem plano gratuito com limites e planos pagos por uso e recursos; a API acompanha o plano do projeto.
Preciso programar para usar a API do Supabase com o iTeam?
Não necessariamente. O iTeam lê a documentação e o esquema liberado e o time de implantação configura as consultas com o seu time técnico.
O agente consegue rodar SQL livre?
Pode, mas recomendamos limitar a visões e consultas definidas, com escrita sob aprovação.
Como o agente de IA lê as tabelas do Supabase pela API REST?
O Supabase gera uma API REST a partir das tabelas do Postgres, e o agente a chama com filtros e seleção de colunas na própria URL. Cada chamada respeita as políticas de segurança por linha (RLS) quando feita com a chave pública. Assim, o agente consulta pedidos de um cliente sem enxergar linhas que a política não libera.
Qual chave do Supabase deve ficar com o agente: a pública ou a de serviço?
A pública, em geral com um usuário de função restrita, porque ela obedece às políticas de RLS. A chave de serviço ignora essas políticas e dá acesso total ao banco, então deve ficar só no servidor e ser evitada em agentes. Se uma tarefa realmente exigir privilégio alto, crie uma função específica no banco e exponha só ela.
O Supabase tem ambiente de teste para validar o agente antes da produção?
Tem o caminho local: a CLI do Supabase sobe um projeto completo na máquina, com banco, autenticação e storage, para testar sem tocar na produção. Também é possível usar um projeto separado, com dados fictícios. Confira na documentação oficial os recursos de branching disponíveis no seu plano, caso queira ambientes temporários por mudança.
Como evitar que o agente exponha dados pessoais ao consultar o Supabase?
Criando visões que trazem só as colunas necessárias e dando ao agente acesso a essas visões, e não às tabelas originais. Um agente de suporte precisa do status do pedido, não do CPF. Combine isso com RLS por cliente e registre as consultas. Assim, mesmo uma pergunta mal formulada não consegue devolver um dado que nunca foi liberado.
O agente pode usar as Edge Functions do Supabase como ferramenta?
Pode: as Edge Functions são endpoints de código no servidor, e o agente os chama como uma ferramenta com entrada e saída bem definidas. É um bom padrão para ações sensíveis, porque a regra de negócio fica no código revisado e o agente só dispara. Em vez de dar acesso direto à tabela de pagamentos, por exemplo, ele chama a função 'reenviar_fatura'.
O Supabase Realtime serve para o agente reagir a mudanças no banco?
Serve: o Realtime transmite inserções, alterações e exclusões das tabelas, e um serviço pode ouvir esses eventos e acionar o agente, como uma nova reclamação aberta. Evita consultas periódicas e reduz o uso do plano. Confira na documentação os limites de conexões simultâneas e mensagens do seu plano, porque eles variam.
Quando não vale a pena colocar um agente de IA sobre o banco do Supabase?
Quando o esquema do banco é instável, as tabelas não têm dono e as regras de acesso ainda não existem. O agente herda essa confusão e pode devolver dados que não deveria. Também não compensa se uma consulta fixa em painel resolve a pergunta. Funciona melhor com dados já estruturados e RLS definida.
O agente consegue executar SQL à vontade no Supabase?
Não é recomendável, e o desenho seguro evita isso: o agente deve usar a API REST com RLS, visões ou funções do banco com parâmetros. SQL livre abre espaço para consultas pesadas e para cruzar dados que não deviam se encontrar. O iTeam trata o banco como fonte de dados com permissões por agente, em vez de dar uma conexão aberta.
