Autenticação
Requisições à API autenticam com um Bearer token emitido nas configurações do seu organização. Tokens são escopados por organização e por role.
Dois tipos de cliente, duas credenciais: chamadas de máquina autenticam com um Bearer token escopado à organização, e pessoas usuárias de browser carregam uma sessão de cookie httpOnly. Esta página declara o contrato dos dois.
Tudo aqui é aplicado no servidor — uma chamada sem autenticação nunca chega à criação de execução, e um token revogado falha fechado.
Credenciais vivem no seu organização, não em contas compartilhadas: cada chamada é atribuível a uma organização e a um papel, e é isso que mantém resultados, limites e trilhas de auditoria separáveis entre clientes.
Bearer token
- Gere em Configurações → Chaves de API (apenas admin).
- Inclua em cada request: `Authorization: Bearer <token>`.
- Tokens são revogáveis; rotacione pelo menos a cada 90 dias.
Gere tokens em Configurações → Chaves de API com conta de administrador e trate-os como segredos de produção: escopados, revogáveis e rotacionados em um ciclo de no máximo 90 dias. O header é o contrato: Authorization: Bearer <token> em cada requisição.
Se um token vazar, revogue-o na mesma tela de Settings → API keys em que foi criado — um token revogado tem o acesso negado na chamada seguinte. Faça a rotação criando primeiro o substituto, implantando-o e só então desativando o valor antigo.
Sessões via cookie
- A web app usa uma sessão de cookie httpOnly para usuários de browser.
- Sessões expiram após 7 dias de inatividade.
- Política same-site é `Lax` para prevenir CSRF em POSTs cross-origin.
Sessões de browser não são uma segunda credencial de API — pertencem à web app. Expiram após 7 dias de inatividade e usam Same-site Lax, que bloqueia CSRF em POSTs cross-origin sem quebrar a navegação normal.
Mantenha as duas credenciais em seus papéis: scripts e CI usam o token, pessoas usam o navegador. Acoplar automação a um cookie de sessão amarra chamadas de máquina a logouts humanos e quebra os dois.