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)
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
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)
https://braidrun.com/api/webhook-trigger/approval/appr-123/approve?api_key=dyk_<id>_<secret>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
Authorization: Bearer dyk_…X-API-Key: dyk_…?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
| Pacote | por minuto | diariamente |
|---|---|---|
| Free | 60 | 2,000 |
| Pro | 300 | 50,000 |
| Team | 1,200 | 500,000 |
| Enterprise | 6,000 | Qualquer |
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/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-WindowDiz- lhe qual a janela atingida (minuto/dia)- Retrocesso exponencial + jitter; não tente imediatamente após receber 429
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 estado | significado | estratégias de enfrentamento |
|---|---|---|
200 | sucesso | — |
202 | Aceito (quando a execução é iniciada) | Pesquisa o estado com a execução devolvidaId |
400 | Corpo de pedido inválido (erro de campo/JSON) | Corrigir o pedido; não tentar novamente |
401 | Token está faltando/formato errado/revogado/ expirado/insuficiente escopo | Verificar novamente o Token e o escopo; não tente novamente |
403 | Conta do proprietário do Token foi desativada/bloqueada | Contacte o administrador da sua conta; não tente novamente |
404 | O recurso não existe ou não tem visibilidade | Verificar ID/scópio; não tentar novamente |
409 | Conflito de estado (por exemplo, a aprovação foi decidida) | Consultar novamente o estado actual |
429 | Limitação de débito | Tente novamente após cumprir com o Retry-After |
500/502/503 | Erro no servidor | Retrocesso exponencial + jitter, repetir 3-5 vezes |
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.