Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.atriby.com/llms.txt

Use this file to discover all available pages before exploring further.

A Orders API usa token bearer server-side. O token deve ficar no seu backend e nunca deve ser exposto no HTML, no script de UTMs ou em código frontend.

​
Formato dos tokens

Tokens novos usam o prefixo: 
atb_live_...
Instalações antigas podem ter tokens utmk_live_*. Eles continuam válidos enquanto existirem, mas novas integrações devem usar tokens atb_live_*.

​
Como enviar

Inclua o header em todas as chamadas da Orders API: 
Authorization: Bearer <api_token>

​
Plaintext aparece uma vez

Ao criar o token no app, o valor completo aparece somente na criação. Depois disso, a interface mostra apenas prefixo/identificador mascarado. Se perder o token, crie um novo e revogue o antigo.

​
Respostas de autenticação

SituaçãoStatusCódigo
Token ausente ou inválido401UNAUTHORIZED
Token revogado403TOKEN_REVOKED

​
Rate limit

A Orders API pode retornar 429 RATE_LIMIT_EXCEEDED quando um token faz muitas chamadas em pouco tempo. No MVP atual, esse controle é por token e local ao processo que recebeu a requisição; trate Retry-After como o contrato público, não como uma quota global garantida. Automatizações devem usar Idempotency-Key em POST e PATCH e aplicar retry com backoff.

​
Boas práticas

  • Guarde o token como variável de ambiente no backend.
  • Nunca envie o token para o navegador.
  • Nunca grave o token completo em logs, auditoria, analytics ou ferramentas de suporte.
  • Use um token por ambiente: produção, staging e testes.
  • Revogue imediatamente qualquer token que possa ter vazado.
  • Use Idempotency-Key em POST e PATCH para retries seguros.