Obter Documentos Reutilizáveis
Use este endpoint para verificar se um usuário já possui um documento disponível para reutilização antes de iniciar um novo fluxo de captura de Document. Se um documento for encontrado, o documentId pode ser passado diretamente para POST /processes/v1 (tipo Document) para pular a etapa de captura.
Endpoint
| Ambiente | URL |
|---|---|
| Produção | GET https://api.idcloud.unico.app/documents/v1 |
| Sandbox | GET https://api.idcloud.uat.unico.app/documents/v1 |
Requisição
| Header | Valor |
|---|---|
Authorization | Bearer <access_token> (veja Autenticação) |
APIKEY | API key provisionada com Captura de Documentos e Reutilização habilitada. |
| Parâmetro | Tipo | Obrigatório | Descrição |
|---|---|---|---|
code | string | sim | Identificador do usuário (CPF ou CURP, sem formatação). |
type | string | sim | Tipo de documento a consultar. Valores aceitos: BR_RG, BR_CNH, BR_CIN, BR_PASSPORT. |
Os valores de type acima são específicos deste endpoint. Não os confunda com:
subject.duiTypeem requisições POST — usa o prefixoDUI_TYPE_*e identifica a pessoa, não o tipo de documento (ex.:DUI_TYPE_BR_CPF).documentTypena resposta — usa o caminho completo do registro (ex.:unico.moja.dictionary.br.cnh.v2.Cnh).
Exemplo
- cURL
- Node.js
curl -X GET "https://api.idcloud.unico.app/documents/v1?code=12345678909&type=BR_CNH" \
-H "Authorization: Bearer $TOKEN" \
-H "APIKEY: $API_KEY"
import fetch from 'node-fetch';
const params = new URLSearchParams({ code: '12345678909', type: 'BR_CNH' });
const res = await fetch(
`https://api.idcloud.unico.app/documents/v1?${params}`,
{
headers: {
Authorization: `Bearer ${accessToken}`,
APIKEY: apiKey
}
}
);
const data = await res.json();
// data.items[0].documentId → passe para POST /processes/v1 para reutilização
Respostas
{
"items": [
{
"documentType": "unico.moja.dictionary.br.cnh.v2.Cnh",
"documentId": "doc-abc-123"
}
]
}
| Campo | Tipo | Descrição |
|---|---|---|
items | array | Lista de documentos reutilizáveis encontrados para o usuário. Array vazio se nenhum documento reutilizável foi encontrado para o code e type fornecidos. |
items[].documentType | string | Identificador do tipo de documento. Valores possíveis: unico.moja.dictionary.br.rg.v2.Rg, unico.moja.dictionary.br.cnh.v2.Cnh, unico.moja.dictionary.br.cin.v1.Cin, unico.moja.dictionary.br.passaporte.v1.Passaporte. |
items[].documentId | string | Identificador do documento. Passe este valor em document.documentId no POST /processes/v1 para reutilizar o documento. |
Usando o documentId para reutilização
Depois de obter um documentId, passe-o na requisi ção do processo Document para pular a captura:
{
"subject": {
"code": "12345678909",
"name": "Luke Skywalker"
},
"document": {
"purpose": "onboarding",
"authProcessId": "<biometric-process-id>",
"documentId": "doc-abc-123"
}
}
| Campo | Descrição |
|---|---|
document.purpose | Finalidade de negócio deste processo de documento. Valores aceitos: creditprocess, carpurchase, paybypaycheck, onboarding, fgts. Esses valores são específicos da Document API e diferem do enum purpose do SDK biométrico. |
document.authProcessId | ID do processo biométrico previamente criado para este usuário (a partir de POST /processes/v1). |
document.documentId | ID do documento obtido na resposta deste endpoint. Quando informado, document.files pode ser omitido — a plataforma recupera automaticamente o documento previamente capturado. |
Códigos de Erro
- 400 Bad Request
- 403 Forbidden
- 404 Not Found
- 429 Too Many Requests
- 500 Internal Server Error
| Código | Mensagem | Descrição |
|---|---|---|
20507 | O parâmetro subject.code é inválido. | Valor de identificador malformado ou inexistente (CPF ou CURP). |
20002 | O parâmetro APIKey não foi informado. | Header APIKEY ausente. |
20001 | O parâmetro authtoken não foi informado. | Header do token de autenticação ausente. |
Bearer token ou APIKEY ausente, expirado ou inválido.
| Código | Mensagem | Descrição |
|---|---|---|
30020 | The provided authorization token does not have permission to perform this action. | Token sem permissão para acessar a selfie do documento. |
30017 | User does not have permission to perform this action. | JWT malformado ou usuário sem permissão para realizar esta operação. |
10502 | O token informado está expirado. | Access-token expirado. |
10501 | O token informado é inválido. | Token de autenticação inválido. |
10201 | O AppKey informado é inválido. | APIKEY ausente ou inexistente. |
| Código | Mensagem | Descrição |
|---|---|---|
99987 | Attachment not found. | Anexo associado ao documento não foi encontrado. |
50001 | The process is not found. | Nenhum documento encontrado para os parâmetros fornecidos. |
Limite de taxa atingido. Quando seu sistema recebe um erro HTTP 429, você deve implementar mecanismos para prevenir falhas em cascata e evitar o agravamento da restrição.
Boas práticas:
- Período de resfriamento (backoff): Interrompa ou reduza imediatamente as requisições subsequentes do seu sistema. Não reenvie continuamente requisições com falha em um loop curto.
- Filas e limitação (Queueing & throttling): Armazene em buffer ou enfileire as requisições de saída do seu lado para controlar o fluxo de tráfego antes de reenviá-las.
- Backoff exponencial com jitter: Ao retentar, aumente o tempo de espera exponencialmente entre as tentativas (por exemplo, 1 s, 2 s, 4 s, 8 s) e adicione um pequeno atraso aleatório ("jitter") para evitar um efeito de manada onde todas as requisições enfileiradas retentam exatamente no mesmo milissegundo.
Enviar requisições continuamente a um endpoint com limite de taxa sem aplicar backoff pode prolongar o período de restrição e impactar severamente a capacidade operacional do seu sistema. Limitar adequadamente as requisições do seu lado garante uma integração mais suave e resiliente.
Para limites padrão, aumento de requisições e detalhes adicionais, consulte Limites de taxa.
| Código | Mensagem | Descrição |
|---|---|---|
99999 | Internal failure! Try again later. | Erro de processamento no lado do servidor. |