Skip to main content
Esta página resume o que integradores devem observar ao operar a Atriby com segurança.

​
Tokens e Authorization

  • Use Authorization: Bearer <api_token> apenas no backend.
  • Tokens novos usam atb_live_*; tokens legados utmk_live_* continuam compatíveis enquanto existirem.
  • O valor completo do token aparece somente na criação.
  • Nunca exponha token no script de UTMs, no HTML, em apps mobile públicos ou no console do navegador.
  • Nunca logue o header Authorization ou o token completo.

​
PII em pedidos

A Atriby aceita alguns dados de cliente no pedido, mas eles devem ser usados com cuidado. A sanitização remove campos sensíveis conhecidos em payloads de auditoria e webhook:
  • customer.email
  • customer.phone
  • customer.document
  • customer.ip
  • headers de autorização, hottok e toda chave cujo nome termina em secret, em qualquer nível
  • token completo
Não envie PII em campos livres como metadata ou trackingExtras. A sanitização é por chaves conhecidas e não deve ser tratada como substituta de uma política de dados.

​
Webhook secrets

Ao criar um webhook, o segredo whsec_... aparece somente uma vez. Salve em um cofre e use para validar o header x-atriby-signature. A assinatura é:
Recomendações:
  • Compare assinatura com método timing-safe.
  • Rejeite timestamps muito antigos.
  • Use x-atriby-delivery para deduplicar retries.
  • Mantenha HTTPS no endpoint consumidor.

​
OrderEvent.payload

Criação e atualização de pedidos geram eventos, a trilha do pedido. O payload de cada evento é o pedido no contrato da API, e nunca o corpo de uma plataforma: uma venda que chega da Cakto, da Lastlink ou da Shopify grava na trilha o pedido já traduzido. O corpo original da plataforma fica no registro da entrega, que não sai pela API. No GET /api/v1/orders/{externalId}, na resposta do PATCH (e portanto no que a idempotência repete) e na aba “Pedido registrado” do painel, o payload de cada evento passa por uma lista de permissão por campo: Um campo só sai se tiver o tipo que o contrato declara (texto, número ou booleano). Chave que o contrato não tem não sai, e payload que não é objeto sai como null. Eventos gravados antes de 30/09/2026 podem conter o corpo de uma plataforma. Esses saem como o marcador abaixo, sem tentativa de filtro. Os campos do pedido continuam na própria resposta.
Mesmo assim, envie apenas dados necessários para atribuição, reconciliação e auditoria operacional.

​
Headers de segurança do app

O app aplica headers como HSTS, X-Frame-Options=DENY, X-Content-Type-Options=nosniff, Referrer-Policy=strict-origin-when-cross-origin e CSP em modo report-only.

​
Responsabilidade do integrador

  • Proteja o token como segredo de produção.
  • Use idempotência em retries.
  • Não misture dados reais e testes sem isTest.
  • Não envie PII fora dos campos previstos.
  • Valide webhooks antes de processar eventos.