​
Autenticação

Use este fluxo para gerar o token JWT usado nas chamadas protegidas da API idCerberus. A autenticação é o primeiro passo antes de consumir onboarding, serviços de pessoa física, serviços de pessoa jurídica ou operações de customers. As credenciais de acesso são compostas por client e secret, fornecidos previamente pela React IT. Caso você ainda não possua essas credenciais, entre em contato pelo e-mail [email protected]. Nossa equipe poderá orientar o processo de criação da conta e liberação do acesso necessário para a integração via API.

​
O que é, por que existe, pra que serve

  1. O que é: o passo que transforma client + secret em um access_token (JWT) de curta duração, que sua aplicação usa em toda chamada protegida.
  2. Por que existe: client e secret são credenciais de longa duração. Se vazarem, o estrago é permanente até serem trocadas. O access_token expira em minutos, então mesmo que vaze, a janela de risco é pequena. Por isso as chamadas do dia a dia usam o token, não o client/secret diretamente.
  3. Pra que serve pra você: define uma peça de infraestrutura da sua aplicação, algo no seu back-end que gera e renova o token automaticamente, para o resto do código nunca se preocupar com isso.
Não. Gere um token e reutilize até ele expirar (expires_in). Gerar um novo a cada chamada funciona, mas é desperdício de uma chamada extra por request.
A chamada retorna erro de autenticação (401). Gere um novo token e repita a chamada original. Veja Status e erros para o tratamento completo.
Não. São credenciais diferentes por ambiente. Um client/secret de HML não gera token válido para chamar produção, e vice-versa.

​
Quando usar

Use esta página quando precisar:
  1. gerar um token de acesso para chamadas protegidas;
  2. entender como enviar o header Authorization;
  3. identificar o tempo de expiração do token;
  4. preparar a autenticação antes de testar os endpoints da API Reference.

​
Fluxo recomendado

  1. Receba as credenciais client e secret.
  2. Gere um token em POST /api/token-generate.
  3. Guarde o valor de access_token no back-end da sua aplicação.
  4. Envie o token no header Authorization.
  5. Gere um novo token quando o anterior expirar.

​
Ambientes

O endpoint de autenticação existe em homologação e produção. O payload é o mesmo; troque apenas a URL base conforme o ambiente. Na prática, o curl de produção é igual ao de HML; a diferença é a URL informada no --location.

​
Gerar token

Gere um token para acessar os serviços da API enviando o client e o secret.
O retorno contém o token de acesso e o tempo de expiração.

​
Como testar

Você pode gerar o token pelo Postman, pelo PowerShell/CMD no Windows ou pelo terminal do macOS/Linux.

​
No Postman

  1. Crie uma requisição POST.
  2. Use a URL https://backoffice-hml.idcerberus.com/api/token-generate.
  3. Na aba Headers, adicione Content-Type com valor application/json.
  4. Na aba Body, selecione raw e depois JSON.
  5. Cole o body com client e secret.
  6. Clique em Send.
  7. Copie o campo access_token retornado.

​
No Windows

No PowerShell, use curl.exe para evitar conflito com comandos internos:
No CMD, use ^ para quebrar linhas:

​
No macOS ou Linux

Use o comando curl no terminal: Exemplo com curl em HML:
Exemplo com curl em produção:
Exemplo de resposta:

​
Usar token

Envie o token retornado no header Authorization das próximas requisições protegidas.
Exemplo em uma chamada de serviço em HML:
Exemplo em uma chamada de serviço em produção:

​
Boas práticas

  1. Mantenha client e secret apenas no back-end da aplicação.
  2. Não exponha credenciais em aplicativos mobile, front-end ou repositórios.
  3. Renove o token quando expires_in indicar expiração.
  4. Trate respostas de autenticação inválida regenerando o token antes de repetir a chamada.
Para detalhes técnicos do endpoint, consulte a API Reference.

​
Próximo passo

Quickstart

Use o token recém-gerado para fazer sua primeira chamada completa.

Escolha o serviço certo

Encontre o código service certo pra usar depois do token.

Status e erros

Veja como tratar token expirado e outros erros de autenticação.

Backoffice

Diferente do client/secret: veja como funciona o login pessoal.