Skip to main content
Neste guia você cria uma análise de risco de CNPJ, acompanha o processamento até o veredito final e repete o fluxo para um CPF. É o mesmo motor que roda na interface web do Sherlocker, agora acessível por API.
Não confunda com o Motor de Borderô (análise de borderô CNAB 400). O Motor de Análise avalia o risco cadastral de um CNPJ ou CPF individual.

Pré-requisitos

  • Acesso ao beta: a feature analysis_engine precisa estar habilitada no seu workspace. Solicite em /api/access.
  • Chave de API: criada no app Sherlocker em Settings → API Keys. As chaves têm prefixo slhk_ e são exibidas uma única vez — guarde em local seguro.
  • Saldo de tokens: as análises consomem tokens do mesmo pool do workspace usado no app.
A base URL de todos os exemplos é https://221b-api.sherlocker.com.br/api/v1.
Os Motores usam a mesma base da API 221b (https://221b-api.sherlocker.com.br/api/v1), mas autenticam via Authorization: Bearer slhk_…não via ?token=.
Diferente das demais APIs documentadas neste site, o Motor de Análise não usa ?token= na URL. A autenticação é sempre pelo header Authorization: Bearer slhk_sua_chave_aqui. Veja Autenticação.
1

Crie uma análise de CNPJ

Envie um POST /analyses com o documento. O header Idempotency-Key é obrigatório — use um UUID novo por análise:
O documento pode ir com ou sem máscara — a API remove os não-dígitos e detecta o subject_type pelo tamanho (14 dígitos → pj, 11 → pf). Sem engine_id, a análise usa a engine padrão do workspace ou o template do sistema (veja Engines).Resposta (202 Accepted):
Os tokens são debitados na criação e confirmados em tokens_charged e balance, quando disponíveis (valores acima são ilustrativos — o preço por análise está em definição durante o beta; veja Cobrança). Guarde o id: é com ele que você consulta o resultado.
Em timeout ou erro 5xx, reenvie o POST com a mesma Idempotency-Key — se a requisição original tiver sido processada, você recebe 200 com a resposta original, sem nova cobrança (janela de 24 horas); se ela ainda estiver em andamento, você recebe 409 e deve consultar via GET com o id da 202 original. Detalhes em Idempotência.
2

Acompanhe até o veredito

Consulte GET /analyses/{id} até o status ficar terminal (completed ou failed). Enquanto a análise está pending ou running, a resposta traz poll_after_seconds no body e Retry-After no header — honre esse intervalo (consultar mais rápido não acelera o resultado, e o limite global é de 100 requisições por minuto por IP):
Fluxo de status: pendingrunningcompleted | failed. Por ora a API é polling-only (sem webhooks).Resposta (200, análise concluída):
Os três campos que importam para a sua decisão:verdict, blocks e coverage são null enquanto a análise está pending ou running. O detalhe de cada verificação está no catálogo de blocos.
3

Analise um CPF (PF)

O mesmo endpoint aceita CPF. Para análises de pessoa física, você pode informar também a base legal LGPD (legal_basis) e a finalidade (purpose) — ambos os campos são opcionais e, quando enviados, ficam gravados no log de auditoria PF do workspace:
Valores aceitos em legal_basis: consentimento, legitimo_interesse, cumprimento_obrigacao_legal, protecao_credito. O acompanhamento é idêntico ao Passo 2 — a resposta virá com subject_type: "pf" e os blocos do template PF.
Análises de CPF exigem a feature analysis_engine_pf habilitada no workspace, além da analysis_engine. Sem ela, a API responde 403 feature_not_enabled com o campo request_access_url apontando para a página de solicitação de acesso.

Tratamento de erros

Todos os erros seguem RFC 7807 (Content-Type: application/problem+json). Use o campo code para decidir o que fazer — o campo type é apenas um identificador. Exemplo de saldo insuficiente (valores ilustrativos): Resposta (402):
Python
O registro completo dos 11 códigos de erro, com os campos extras de cada um, está em Erros.

O que você construiu

  • Um fluxo completo de análise: POST /analyses (202) → polling em GET /analyses/{id} → veredito em verdict, detalhe por verificação em blocks e rastreabilidade das fontes em coverage.
  • Submissão segura contra duplicidade com Idempotency-Key — retries não geram cobrança dupla.
  • Polling que respeita poll_after_seconds / Retry-After.
  • O mesmo fluxo para CNPJ (pj) e CPF (pf), com base legal e finalidade auditadas no caso PF.

Próximos passos

Ciclo de vida

Estados da análise, polling e o que muda em cada transição

Idempotência

Retries seguros, janela de 24h e resolução de conflitos 409

Cobrança

Quando os tokens são debitados e quando há reembolso automático