Headers HTTP

Em toda request feita pelo @cactus-agents/api-client (incluindo loaders SSR e proxies de API route), uma família de headers X-ORIGIN-* é injetada automaticamente. Esta página documenta cada um — eles aparecem no Network tab do DevTools e são lidos pelo BFF para anti-fraude e atribuição.

X-ORIGIN-REFERRER

URL completa do first external referrer (a primeira URL externa que trouxe o user pra brand).

Origem: cookie_referrer.referrer. Capturado uma única vez na primeira navegação do tab via document.referrer.

Exemplo:

X-ORIGIN-REFERRER: https://www.google.com/search?q=cassino+online

Vazio quando: user veio de digitar a URL diretamente (referrer empty), ou veio de domínio interno.

X-ORIGIN-HOSTNAME

Hostname extraído do referrer.

Exemplo:

X-ORIGIN-HOSTNAME: google.com

Mais útil que a URL completa pra agregação em BI ("quantos users vieram do Google?").

X-ORIGIN-CINFO-ID / X-ORIGIN-CINFO-ID-REF

IDs de tracking gerados pelo BFF e ecoados em headers de response (X-INFOS-ID / X-INFOS-REF) após login ou register. Persistidos no cookie_referrer e enviados de volta em todas as requests subsequentes.

Exemplo:

X-ORIGIN-CINFO-ID: abc123
X-ORIGIN-CINFO-ID-REF: def456

Pra que serve: o BFF correlaciona requests do mesmo user/device numa "sessão lógica" maior que a do JWT. Útil pra anti-fraude (detectar troca de IP, troca de device fingerprint, etc).

X-ORIGIN-ACCESS

Enum 1-5 indicando o tipo de cliente que está fazendo a request:

Valor	Significado	Como é detectado
1	App	TWA bridge ativo (window.twa)
2	Desktop	User-Agent não-mobile, sem ?app=true
3	DesktopApp	Desktop + app mode (raro — Electron etc)
4	Mobile	User-Agent mobile sem TWA
5	MobileApp	Mobile com TWA bridge

Server-side: detectado por regex no User-Agent + presença de ?app=true. Client-side (futuro): matchMedia('(display-mode: standalone)') quando o usuário instala como PWA.

Exemplo:

X-ORIGIN-ACCESS: 4

X-LOG-INFO

Header de tracing único por request, formato 1-{timestamp}-{buildId}.

Exemplo:

X-LOG-INFO: 1-1731000000000-8f2c1a4b3d3e

Componentes:

• 1 — versão fixa do schema
• {timestamp} — epoch ms quando a request foi montada
• {buildId} — primeiros 12 chars do commit SHA do deploy

Pra que serve: tracing server-side. Cada log linha do BFF carrega esse ID, permite correlacionar uma request específica do user a logs internos. Quando reportar um bug, sempre incluir o X-LOG-INFO que apareceu no Network — desbloqueia investigação rápida.

Headers que NÃO são tracking (mas valem mencionar)

Authorization

JWT do user logado. Só presente quando user tem sessão válida. Lido do cookie jwt_token (HttpOnly).

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6Ikp...

cf-worker-key (server-only)

Chave compartilhada entre o front e o BFF que prova que a request veio de um Worker autorizado. NUNCA é enviada do browser direto — só de Worker pra Worker. Bug de segurança histórico em maio/2026 quando esse header vazou em response client (ver Anti-patterns no Internal Docs).

Tabela-resumo

Header	Origem	Quando aparece
X-ORIGIN-REFERRER	cookie_referrer.referrer	Sempre que cookie estiver populado
X-ORIGIN-HOSTNAME	cookie_referrer.hostname	Sempre que cookie estiver populado
X-ORIGIN-CINFO-ID	cookie_referrer.cinfoId	Após primeiro login/register
X-ORIGIN-CINFO-ID-REF	cookie_referrer.cinfoIdRef	Após primeiro login/register
X-ORIGIN-ACCESS	User-Agent + ?app=true	Sempre
X-LOG-INFO	gerado por request	Sempre
Authorization	jwt_token (HttpOnly)	Só users logados

UTMs NÃO vão em headers

UTMs / clicked-IDs / ga_client_id / affiliation_code viajam só no body dos POSTs de signup e deposit — nunca em headers.

Por quê? Headers HTTP têm limite de tamanho mais restrito (~8KB total na maioria dos servers). UTMs custom (utm_oferta, utm_term, utm_creative...) podem facilmente passar disso. Body permite payload grande sem problemas.

Detalhes do payload em UTMs → Payload final pro BFF.

Como inspecionar no DevTools

1. DevTools → Network → filtra por XHR ou Fetch
2. Clica numa request pro /api/*
3. Aba Headers → seção Request Headers → procura por X-ORIGIN-* e X-LOG-INFO

Se algum header esperado estiver ausente, provável causa: cookie correspondente não existe (ex: X-ORIGIN-CINFO-ID ausente porque user nunca logou, ou cookie expirou).

Anti-patterns

1. Adicionar UTM em header. Quebra ao primeiro UTM custom > 1KB. Vai sempre no body.
2. Tentar sobrescrever X-LOG-INFO no client. É gerado pelo SDK. Mexer quebra tracing server-side.
3. Confiar em X-ORIGIN-REFERRER pra atribuição. É só first-touch do tab. Atribuição last-touch real está no cookie_tracking.utm_source.