Guia de Autenticação
Guia de Autenticação
Este guia explica passo a passo como obter um token de acesso para utilizar a API PIX da CorpX.
Visão Geral
A API CorpX utiliza OAuth 2.0 com o fluxo Client Credentials para autenticação. Você precisará das suas credenciais (client_id e client_secret) para obter um token de acesso válido.
Pré-requisitos
Antes de começar, certifique-se de que você possui:
- Client ID - Seu identificador único de cliente
- Client Secret - Chave secreta para autenticação
- X-Tenant-Id - Seu identificador de tenant (ex.:
tenant-suaempresa)
Se você ainda não possui credenciais, entre em contato com nossa equipe de suporte.
Ambientes
Passo 1: Solicitar um Token de Acesso
Request
Parâmetros
Resposta de Sucesso (200 OK)
O access_token vale 5 minutos (expires_in: 300) e deve ser reutilizado
em todas as chamadas até expirar. Gerar um token novo a cada request é
proibido: esgota o Cognito, atrasa a sua integração e pode fazer a emissão
ser recusada.
Guarde o token no seu lado. Só chame /oauth2/token de novo quando faltar
cerca de 60 segundos para o expires_in acabar, ou quando a API responder
403 de token expirado. Não fixe o TTL no cliente — leia o expires_in da
resposta.
Resposta de Erro (401 Unauthorized)
Passo 2: Usar o Token nas Requisições
Com o token obtido, inclua-o no header Authorization de todas as requisições à API.
Exemplo: Consultar Saldo
Headers Obrigatórios
Passo 3: Renovar o Token
O token expira após o tempo indicado em expires_in (5 minutos nas
credenciais atuais). É obrigatório reutilizar o mesmo token até perto
desse prazo:
- Armazene o token em cache com o
expires_inque veio na resposta - Renove antes de expirar — com TTL de 5 minutos, renovar no último minuto já é apertado
- Trate o 403 de token expirado — a API responde
403 Forbidden, não401; ao recebê-lo, obtenha um novo token e repita a chamada
Exemplo de Renovação Automática (Bash)
Exemplos Completos em Diferentes Linguagens
Python
Node.js
Escopos de credencial
Cada credencial (client_id/client_secret) carrega um conjunto de escopos
que define exatamente o que ela pode fazer. Você escolhe os escopos ao criar a
credencial no painel do backoffice (seção API Credentials, disponível para
usuários com perfil tenant manager).
Escopos que você mesmo concede:
kyc.read é o único escopo de consulta que não é coberto por read: como
ele entrega rosto de cliente, precisa ser concedido explicitamente. A rota
também exige a feature kyc_artifacts habilitada no tenant — veja
Arquivos comprobatórios.
Cada escopo já consulta o próprio domínio. É o que permite uma credencial de
recebimento que emite QR code e vê se ele foi pago sem ter acesso ao saldo e
ao extrato: basta conceder qrcode.manage sozinho. Marque read apenas quando a
credencial precisar realmente das consultas amplas da conta.
Escopos que movimentam dinheiro são emitidos pela CorpX, nunca pelo painel:
Se você pedir um desses escopos pelo painel, a criação é recusada com
403 scope_not_self_service — fale com o suporte para emitirmos a credencial.
Credenciais delegadas
O escopo credentials.delegate é CorpX-only: a master do internet banking emite
filhas amarradas a uma conta. Se você recebeu essa filha (feature API do
IB), esta seção BaaS não é o seu guia — vá para
Internet banking.
Restrição por conta
Uma credencial pode ficar restrita a contas específicas do seu tenant. É o
caminho para, por exemplo, dar a um subsistema uma credencial que só emite QR
code de uma conta. Chamadas a contas fora do conjunto respondem
403 forbidden — o erro genérico de permissão, sem insufficient_scope: o
escopo está lá, a conta é que não. A mensagem não distingue conta inexistente
de conta fora do conjunto, de propósito.
Combinando as duas dimensões: qrcode.manage + uma única conta resulta numa
credencial que cobra por QR code naquela conta e não enxerga mais nada — nem o
saldo dela, nem as outras contas do tenant.
Quando falta escopo
Se a credencial não tem o escopo da rota, a API responde 403 Forbidden
nomeando o que falta:
Credenciais emitidas antes dos escopos granulares continuam funcionando sem
alteração: elas mantêm o par grosso (api2/read api2/write) e acesso total.
Acesso suspenso por pendência
Quando existe uma pendência em aberto com a CorpX, o acesso do tenant pode ser
suspenso temporariamente. A suspensão não invalida sua credencial: o mesmo
client_id/client_secret continua obtendo token normalmente, e a recusa vem
na chamada à API.
Dois pontos importantes:
- O dinheiro não para. PIX recebido continua sendo creditado, e você continua recebendo os webhooks desses eventos. O que a suspensão bloqueia é iniciar novas operações.
- Reativar é imediato. Assim que a pendência é regularizada, o acesso volta na chamada seguinte — não é preciso gerar credencial nova nem novo token.
O motivo da pendência não vem no corpo do erro: ele aparece no painel do backoffice, para os operadores do seu time.
Erros Comuns
Boas Práticas
- Reutilize o token — um token por chamada é proibido
- Nunca exponha o
client_secretem código client-side (frontend) - Use variáveis de ambiente para armazenar credenciais
- Monitore a expiração e renove tokens de forma proativa
- Use HTTPS para todas as comunicações
Próximos Passos
Agora que você sabe como autenticar, explore os outros guias:
- Guia de QR Code Dinâmico - Gerar cobranças PIX
- Guia de Cash Out - Fazer transferências PIX
- Guia de Devolução - Solicitar estornos