​

Visão geral

​

Como tudo se encaixa

​

Service

1. O que é: uma consulta ou verificação específica, como “situação do CPF na Receita Federal” ou “comparar selfie com documento”. Tem um código próprio (SERVICE_ALGUMA_COISA) e devolve um resultado isolado.
2. Por que existem mais de 300: cada tipo de dado ou verificação vira um service diferente, porque cada empresa usa uma combinação diferente deles. Você nunca precisa de todos.
3. Pra que serve pra você: é a unidade que você efetivamente chama. Toda implementação começa por decidir quais services resolvem o seu problema. Veja Escolha o serviço certo.

​

Consulta avulsa vs. onboarding

1. O que é: duas formas de usar um service. Avulsa é chamar um service sozinho, na hora, direto em POST /api/service-api. Onboarding é combinar vários services em uma jornada guiada, com etapas, campos capturados e um status final (APPROVED, IN_PROCESS, REFUSED).
2. Por que as duas existem: nem toda necessidade é um cadastro completo. Às vezes você só precisa confirmar um dado pontual (avulsa); às vezes precisa conduzir o usuário por um fluxo de KYC inteiro (onboarding).
3. Pra que serve pra você: define o modelo de integração que você vai construir. Se a resposta é “só confirmar um dado agora”, é avulsa via API. Se é “cadastrar o usuário do zero, com documento e selfie”, é onboarding via SDK ou Cliente Web.

​

Produto

1. O que é: a configuração específica da sua empresa, incluindo quais services estão liberados, em qual ordem entram no onboarding e quais ficam disponíveis para consulta avulsa.
2. Por que existe: cada cliente da idCerberus usa um conjunto diferente de services. O produto é o que amarra “API idCerberus” a “o que a sua empresa efetivamente contratou”.
3. Pra que serve pra você: você nunca escolhe entre todos os 300+ services; escolhe dentro do que já foi habilitado para o seu produto. Se um service que você precisa não responde ou não aparece, o primeiro suspeito é ele não estar liberado no seu produto, não um erro de implementação.

​

Dúvidas comuns nessa fase

​

Modelos de integração

1. Backoffice: interface visual da idCerberus, para olhar resultados e testar consultas sem escrever código.
2. Webhooks: avisa sua aplicação quando o status mudar, tanto para onboarding quanto para consulta avulsa, em vez de ela ficar perguntando (polling).

​

Se você está começando agora

1. Gerar token com client e secret.
2. Copiar o access_token retornado.
3. Enviar esse token no header Authorization.
4. Executar o endpoint ou serviço desejado.
5. Ler o objeto result e o status técnico em status.

​

Ambientes

​

Endpoints principais

​

Fluxo mínimo para testar

1. Gere um token em POST /api/token-generate.
2. Envie o token no header Authorization.
3. Escolha um serviço em Pessoa Física ou Pessoa Jurídica.
4. Chame POST /api/service-api com o campo service.
5. Leia status.code, status.message e os dados dentro de result.

​

Padrão dos serviços externos

POST /api/service-api

{
  "service": "SERVICE_PERSON_DATA_ENRICHMENT",
  "cpf": "cpf"
}

​

Padrão de resposta

{
  "result": {},
  "status": {
    "code": 200,
    "message": "Success"
  }
}

​

Próximos passos

1. Para autenticação, veja Autenticação.
2. Para onboarding via SDK, veja Onboarding via SDK.
3. Para catálogo de CPF, veja Serviços de Pessoa Física.
4. Para catálogo de CNPJ, veja Serviços de Pessoa Jurídica.
5. Para implementação endpoint a endpoint, use a API Reference.