Saltar para o conteúdo principal
DocsAPI abrir plataformaAutenticação e limitação de taxas

Autenticação e limitação de taxas

Carregador / X-API-Key / consulta três métodos de escrita, limite de taxa de pacotes, semântica de código de estado HTTP.

Todos os terminais da plataforma aberta são autenticados uniformemente através da API Key. Esta página explica claramente as três maneiras de escrever Tokens, limites de taxa de pacotes e a semântica das respostas de erro.

Três métodos de escrita de autenticação

1. Autorização: Portador (recomendado)

bash
curl https://braidrun.com/api/v1/workflows \
  -H "Authorization: Bearer dyk_<id>_<secret>"

O método de escrita mais padrão, suportado por todos os SDKs por padrão. O ambiente de produção é preferido.

Cabeçalho 2.X-API-Chave

bash
curl https://braidrun.com/api/v1/workflows \
  -H "X-API-Key: dyk_<id>_<secret>"

Adequado para cenários onde o proxy de algumas redes fechadas não pode encaminhar o Cabeçalho de Autorização. Funcionalmente equivalente ao portador.

3. Parâmetro de consulta ?api key= (apenas em cenários onde o Header não pode ser escrito)

text
https://braidrun.com/api/webhook-trigger/approval/appr-123/approve?api_key=dyk_<id>_<secret>
Usar parâmetros de pesquisa com cautela

Parâmetros de consulta serão registrados no histórico do navegador, Cabeçalho de Referência, registros de acesso ao servidor HTTP e registros de CDN. Ele é usado apenas em cenários que devem ser acionados na forma de links GET (como links de aprovação de e-mail/Slack/Telegram com um clique), e é usado com uma chave TTL curta. Nunca abandone a prioridade do Bearer para consultar parâmetros.

Prioridade

  1. Authorization: Bearer dyk_…
  2. X-API-Key: dyk_…
  3. ?api_key=dyk_…

Tente de cima para baixo e pare de analisar quando encontrar um não vazio.

Limitação de débito

Cada API Key tem dois limites superiores de "por minuto" e "diário", que são automaticamente aplicados de acordo com o pacote do proprietário da Chave. Cada chave tem uma quota independente e não é compartilhada com outras chaves na mesma conta.

Tabela de comparação de pacotes

Pacotepor minutodiariamente
Free602,000
Pro30050,000
Team1,200500,000
Enterprise6,000Qualquer

Semântica da janela

  • janela do minuto · Use minutos de época como chave, e o limite é reiniciado automaticamente a cada minuto (não a janela deslizante a partir da primeira chamada)
  • diariamente (janela do dia) · Usar a data UTC como chave, reiniciar automaticamente às 00:00 UTC todos os dias

Quando o limite for atingido

http
HTTP/1.1 429 Too Many Requests
Retry-After: 38
X-RateLimit-Limit: 60
X-RateLimit-Window: minute
Content-Type: application/json

{
  "error": "Rate limit exceeded",
  "window": "minute",
  "limit": 60,
  "retryAfterSeconds": 38
}

O cliente deve:

  • Leia o Cabeçalho de Repetição (número de segundos), atrase o tempo correspondente e tente novamente
  • X-RateLimit-Window Diz- lhe qual a janela atingida (minuto/dia)
  • Retrocesso exponencial + jitter; não tente imediatamente após receber 429
Múltiplas teclas para dividir o tráfego

Precisa de maior rendimento? Chaves independentes são emitidas para diferentes ambientes/integrações diferentes, e cada chave recebe uma quota completa. Um usuário Pro abrindo 3 Chaves equivale a uma capacidade total de 900 RPM. Esta é também a melhor prática para localização de acidentes - quando um problema ocorre, você só precisa olhar para qual chave tem uso anormal.

Código de resposta HTTP

código do estadosignificadoestratégias de enfrentamento
200sucesso
202Aceito (quando a execução é iniciada)Pesquisa o estado com a execução devolvidaId
400Corpo de pedido inválido (erro de campo/JSON)Corrigir o pedido; não tentar novamente
401Token está faltando/formato errado/revogado/ expirado/insuficiente escopoVerificar novamente o Token e o escopo; não tente novamente
403Conta do proprietário do Token foi desativada/bloqueadaContacte o administrador da sua conta; não tente novamente
404O recurso não existe ou não tem visibilidadeVerificar ID/scópio; não tentar novamente
409Conflito de estado (por exemplo, a aprovação foi decidida)Consultar novamente o estado actual
429Limitação de débitoTente novamente após cumprir com o Retry-After
500/502/503Erro no servidorRetrocesso exponencial + jitter, repetir 3-5 vezes
Por que 401 não distingue entre razões

Token faltando, expirado, revogado e escopo insuficiente todos retornam 401 uniformemente, sem expor a razão de falha específica - isso evita que os atacantes usem tentativas e erros para detectar quais chaves existem/que escopos estão habilitados. A razão de falha completa (campo de motivo) é mantida no diário de auditoria e pode ser verificada pelo administrador.