Conta nominal do administrador ativada pelo convite (ou por Esqueceu sua senha?); e-mail verificado e cadastro do autenticador concluído.
Cada etapa do Início está de fato Concluída, não apenas enviada ou Aprovada.
O vínculo/papel vigente e a aplicação/ambiente exatos correspondem à integração.
As origens permitidas do site são origens HTTPS exatas, sem caminho, porta nem curinga.
Configurar a coleta web usa uma das origens da aplicação e o domínio-base que pertence a você; o coletor que ela gera é collect.<base-domain>.
Integração e saúde › Origens das páginas lista todas as origens de página que coletam (por exemplo, o domínio raiz e www), todas sob o domínio de coleta, no máximo 10.
As etapas automáticas de release/política/admissão e de retenção técnica estão concluídas no Início; Aguardando revisão não conta como concluída.
Os demais membros usam contas nominais e o menor papel necessário para o trabalho deles.
Os dados emitidos estão completos e vêm da configuração real/entrega verificada.
A prova de DNS/titularidade/certificado/saúde de collect.<your-domain> está vigente; preparar os registros não é ativação.
O segredo HMAC foi recebido uma única vez no console e guardado no gerenciador de segredos do backend; nenhuma solicitação de credencial continua em Aguardando você receber o segredo.
As permissões reais do cliente e o limite de taxa vigente do cliente de servidor (nível padrão: 5 requisições por segundo, rajada de 10; veja limites) correspondem à configuração do backend.
Sua credencial de servidor está instalada com admissão ativa e seu domínio de coleta está ativo; a API assinada está no ar em produção em modo shadow e a coleta do Web SDK está implantada lá (status).
As provas aplicáveis de segurança/isolamento, as de retenção/descarte técnicos aplicados e as operacionais/de recuperação estão confirmadas.
Release, política e admissão ativos e qualificados e a ativação explícita da aplicação estão registrados antes de dados reais.
O HMAC usa os 32 bytes decodificados vindos do gerenciador de segredos do backend, nunca o texto hexadecimal de 64 caracteres.
Fora da única exibição no console, nenhum segredo real aparece em chat, navegador, e-mail, argumentos/saída de comando, arquivos locais ou repositório.
A autoverificação da assinatura reproduz o vetor sintético público dela no Node.js do backend (24.16.0 ou posterior na série 24; na Vercel, Node.js 24.x).
O relógio do backend está sincronizado; X-FTID-Timestamp está em segundos.
Toda tentativa tem um novo request_id UUIDv7, um novo timestamp e uma nova assinatura, inclusive depois de 429/503.
A requisição fechada é serializada uma única vez com JSON.stringify; as novas tentativas usam exatamente os mesmos bytes e o mesmo token, inclusive null.
Os idempotency_key/external_event_id lógicos são únicos, guardados e nunca gerados de novo depois de um resultado incerto.
Um 410 assessment-result-expired definitivo encerra a reconciliação e nunca cria uma operação histórica substituta.
Content-Type, rota e cabeçalhos exatos; sem Content-Encoding, Expect, seletor de tenant/cliente nem alias de nonce.
A identidade e o horário do evento confiáveis vêm do backend; as referências são pseudônimos com chave opacos, estáveis e sem dados pessoais, o account_ref sempre vai com o mesmo subject_ref, e a chave e o prefixo do HMAC nunca mudam em silêncio (referências de pessoa e de conta).
Integrações novas enviam a requisição v1.1, aceita em produção, com uma etiqueta por ponto de chamada; uma integração que continua no v1 usa só LOGIN, WITHDRAWAL e TRADE, sem mudança.
As etiquetas não contêm dados pessoais e têm no máximo dez dígitos; uma nova tentativa repete a mesma etiqueta.
A avaliação de login fica depois da autenticação concluída no servidor/do MFA exigido; no v1, cadastro/recuperação não inventam jornadas.
Resposta/Problem validados contra o contrato baixado do perfil enviado; evento esperado e etiqueta (v1.1) ou jornada (v1) conferidos.
Nota nula tratada como ausência de nota; a recomendação, a base e as versões efetivas devolvidas ficam preservadas.
Seu sistema executa a própria decisão/fallback; o SHADOW inicial não bloqueia usuários automaticamente.
A rotação consegue manter duas credenciais, passar para a nova e aposentar a antiga dentro da sobreposição aprovada.
A rotação comum preserva as permissões/taxa vigentes e nunca passa de 24 horas de sobreposição; mudar as permissões exige uma configuração separada e revisada.
Correlações de suporte guardadas sem tokens, cookies, dados pessoais nem payloads completos nos logs.
No backend, a origem está configurada como https://api.fingertrackid.com, exatamente como está escrita.
Todo login concluído é avaliado, inclusive com event_context_token: null e em logins sociais/OAuth (orientações de integração).
Falhas da integração nunca bloqueiam o login, e erros de configuração (authentication-failed, forbidden, validation-failed, codificação inválida do segredo) geram um log de erro ou alerta claro.
Um 409 binding-conflict registra um erro no log e dispara um alerta, e o login continua.
A integração fica atrás da sua própria feature flag, habilitada primeiro para contas internas.
A versão exata aprovada do SDK privado foi baixada no console, e o SHA-256/SHA-512 dela foi conferido com o console antes da instalação.
Uma única cópia do SDK, inicializada só no código do navegador, para o ciclo de vida do documento/conta atual.
A origem de coleta ativa exata está no connect-src da CSP; sem URL de script presumida nem coletor alternativo.
Nenhuma instrumentação da página (Sentry, Datadog, OpenTelemetry ou outro wrapper de fetch) adiciona cabeçalhos às requisições para a origem de coleta; as requisições OPTIONS para ela pedem só os cabeçalhos do próprio SDK e recebem 204 (cabeçalhos de rastreamento).
Os dois CNAMEs emitidos continuam DNS-only e o TXT de titularidade mantém o valor emitido; se a verificação expirou, Verificar agora a renovou.
A página usa createActionContextHelper (receita): prefetch() na primeira intenção no formulário da ação avaliada (focusin/pointerdown, nunca no carregamento da página) depois do consentimento aplicável, um take() por ação, e nenhum valor de formulário/senha/código de recuperação chega ao SDK; minRemainingMs fica acima da margem do seu backend (ciclo de vida).
Um login que redireciona para o Google ou outro provedor OAuth coleta antes do redirecionamento ou numa página depois do callback (login com redirecionamentos); o backend registra em log quando um login chega sem token, e por quê.
Toda página que coleta está numa dessas origens permitidas; qualquer outra origem recebe TRANSPORT_ERROR. A continuidade do dispositivo é por origem: o mesmo navegador em www e no domínio raiz conta como duas instalações.
O navegador envia o token com o expiresAt dele; o backend envia null quando resta tempo insuficiente e, diante de 400 event-context-invalid, avalia mais uma vez como uma nova operação com null.
No envio, a página espera o contexto com take(), que se resolve dentro do teto waitMs dele e nunca aborta o SDK; um formulário clássico segura a navegação até então, e uma aplicação de página única mantém o SDK fora de componentes que se desmontam no envio.
O SDK se prepara só em páginas com uma ação avaliada, e close() vem depois da resposta de negócio do backend; assim, sessões não fechadas não ocupam o limite de 1000 sessões.
O SDK instalado é a versão que o console oferece (0.3.0 ou posterior para o helper), e a coleta da sua aplicação está configurada para essa versão; com a 0.1.1, uma nova coleta usa um novo cliente, e o antigo só é fechado quando nenhum token dele estiver pendente (SDK 0.1.1).
Sua política de privacidade descreve a coleta (dados coletados e tratamento), validada pelo seu encarregado de dados (DPO).
Um handle/contexto guardado por nova ação avaliada; as novas tentativas mantêm o resultado capturado, inclusive null.
Falhas de inicialização, de coleta, de contexto síncrono e de rede deixam a autenticação normal funcionando.
O cliente continua vivo durante a primeira tentativa de avaliação, que é limitada; um encerramento de página pendente não estende a validade do token.
Logout/troca de conta chama close() e descarta os handles sem atrasar o logout normal.
As capacidades de feedback solicitadas estão de fato ativas antes das chamadas de ação/desfecho.
O feedback assina o caminho/ID exato da avaliação e valida o próprio contrato de requisição/recibo/Problem.
A ação informada reflete o que seu produto de fato fez; um bloqueio/nota não é verdade sobre fraude.
A análise em modo shadow registra os IDs das avaliações, as recomendações e as suas próprias decisões, e mantém o alinhamento dos recibos de feedback.
A correção de desfecho referencia a folha atual e acrescenta um fato sem reescrever o histórico.
Acessos e Integração e saúde, no console, refletem o escopo pretendido; resultados indisponíveis, truncados ou expirados continuam explícitos.
Com account_ref enviado, o primeiro login de uma conta com coleta do navegador concluída mostra Primeira vez: ainda sem histórico em Contexto do acesso (sem essa coleta, Sem coleta concluída do navegador), e um login posterior dessa conta com contexto do navegador, até 90 dias depois de um login anterior que também teve coleta do navegador com uma instalação de navegador vinculada, mostra Dispositivo novo para esta conta avaliado (Sim ou Não) em vez de Conta não informada pelo sistema da empresa; nenhum 409 binding-conflict aparece nos seus logs.
Vínculo revogado, origem/chave cruzada e estado desconhecido de requisição foram exercitados com dados sintéticos.
Uma solicitação pendente pode ser cancelada com Cancelar a solicitação pendente; os artefatos existentes continuam e um resultado incerto é conferido com Recarregar o estado na mesma solicitação.
Uso interpretado como estimativas, e as exportações como dados com escopo, mascarados e com prazo de expiração, não como faturas nem coleta bruta.
