Token do sincronizador
A credencial que o ERP do cliente usa para alimentar o espelho. É a única chave de escrita da plataforma que não é um usuário — e hoje ela é praticamente inalcançável.
Campos (appstock_core.sync_tokens)
| Campo | Papel |
|---|---|
token_hash | SHA-256, único. O valor em claro nunca é armazenado. |
org_id | FK para ent-organizacao, ON DELETE CASCADE. |
label | Padrão 'default'. Permite mais de um token por organização (agente + ETL, por exemplo). |
revoked | Boolean. resolve_org_by_token filtra por false. Nada no produto seta isso. |
last_used_at | Carimbado a cada chamada autenticada — é o único sinal de vida da integração. |
Como é usado
O sincronizador manda X-Sync-Token em toda chamada de mod-sync-ingest. O SHA-256 do valor
recebido é comparado contra a coluna; a organização vem do token, não do JWT nem da
organização padrão. Ver flx-primeira-carga.
O problema
O token nasce e desaparece. É gerado no passo 6 do flx-onboarding (token_urlsafe(32)) e
devolvido em claro uma única vez:
- CLI (
python -m src.provision) → imprime no JSON de saída. ✅ POST /signup→ não devolve. O comentário no código diz que “o admin o emite/consulta autenticado” — mas esse endpoint não existe.
Consequências, todas verificadas:
| Situação | Hoje |
|---|---|
| Empresa se cadastrou pelo signup público | Recebe uma organização que não tem como ser integrada. Nunca vê o token. |
| Token vazou | Não há como revogar sem UPDATE manual na tabela. |
| Quer um segundo token (agente + ETL) | Só por INSERT manual, embora o label exista para isso. |
| Quer saber se a integração está viva | last_used_at está gravado e nenhuma tela mostra. |
O que falta
Um módulo pequeno e de alto valor: emitir, listar (com label e last_used_at, nunca o
valor), revogar — sob permissão de administrador da organização. É pré-requisito da página de
Integração que a tese “o TI do cliente integra sozinho” exige.
Lacunas
Rastreadas na fase-1-onboarding.