O que é a plataforma Unico IDCloud?

IDCloud é a única plataforma de verificação de identidade que combina segurança com precisão garantida. Com ela, é possível validar a identidade de usuários de maneira simples e intuitiva, utilizando apenas uma selfie, garantindo fluidez e proteção nos seus processos de verificação.

Visão geral da integração

Visão Geral

Bem-vindo à documentação das APIs REST da plataforma Unico IDCloud! Nesta página, você encontrará tudo o que precisa saber para melhorar a segurança e a qualidade dos seus aplicativos usando nossa REST API.

Leia mais

Para atender os mais variados casos de uso da sua operação, as capacidades do IDCloud possuem diferentes disponibilidades de acordo com os meios de integração. Abaixo confira a tabela com todas as possibilidades de utilização, separadas por meio de integração:

Abaixo veja detalhadamente como funciona cada capacidade:

Prova de vida

Quando há a necessidade de identificar se a pessoa é real e está viva no momento da operação. Pode ser utilizada de forma isolada ou em conjunto com as capacidades de Verificação de Identidade, Alerta de comportamento, Score de risco e Validação (1:1). Deve ser sempre utilizada em conjunto com os SDKs.

As possibilidades de resposta são:

• SIM: indica que o usuário está ao vivo no momento da captura da seflie;

• NÃO: indica que o usuário não está ao vivo no momento da captura da selfie.

Verificação de Identidade

Quando há a necessidade de garantir que o usuário que está realizando o processo é quem diz ser. Por padrão, é sempre utilizada em conjunto com a capacidade Prova de vida.

As possibilidades de resposta são:

• SIM: indica que a face é a do real titular do CPF;

• NÃO: indica que a face não é a do real titular do CPF;

• INCONCLUSIVO: indica que não temos evidências suficientes para garantir se a face é ou não do real titular do CPF.

Alerta de Comportamento

O Alerta de Comportamento complementa a resposta de Verificação de Identidade, trazendo o componente de comportamento que dá a certeza de um risco atrelado àquela identidade, visto comportamento fraudulento anterior. Só pode ser utilizado em conjunto com a capacidade Verificação de Identidade.

As possibilidades de resposta são:

• SIM: indica que a face já esteve envolvida em transações fraudulentas de identidade;

• SUSPEITO: indica que a face já teve pelo menos uma passagem em nossa base com outro identificador;

• INCONCLUSIVO: indica que não temos indícios suficientes que a face esteja envolvida em transações fraudulentas em nossa base.

Score de risco

Quando há a necessidade de se obter um score de probabilidade sobre o usuário que está realizando o processo é quem diz ser. Só pode ser utilizada em orquestração com a capacidade de de Verificação de Identidade quando a resposta desta é "INCONCLUSIVA".

As possibilidades de resposta são:

• Score Positivo: pode variar entre +10 e +100. Quanto maior o score, maior a probabilidade da face ser a real titular do CPF;

• Score Zero: quando há algum erro de cadastro. Indicamos que seja feita uma nova captura;

• Score Negativo: pode variar entre -10 e -100. Quanto menor o score, maior a probabilidade da face não ser a real titular do CPF.

Validação (1:1)

Quando há a necessidade de reconhecer se a pessoa da operação é a mesma que realizou o cadastro. Por padrão, é sempre utilizada em conjunto com a capacidade Prova de vida. Só pode ser utilizado em casos onde já foi feito um processo de Verificação de Identidade.

As possibilidades de resposta são:

• SIM: indica que a face que está realizando a transação é a mesma que realizou o processo utilizado como referência;

• NÃO: indica que a face que está realizando a transação não é a mesma que realizou o processo utilizado como referência.

Reaproveitamento e captura de documentos

Quando há a necessidade de solicitar, armazenar e reutilizar documentos. Oferecemos a possibilidade de reaproveitar os documentos pessoais dos usuários (Passaporte brasileiro, CIN, RG e CNH - digital e comum), diminuindo a fricção desse processo que costuma ser de alta desistência, com um produto inédito no mercado. E caso não tenhamos os documentos na base, é possível capturá-los.

Só pode ser utilizado em conjunto com a capacidade Verificação de Identidade, pois trabalhamos com alta confiabilidade para o compartilhamento dos documentos. Além disso, tanto para o reaproveitamento quanto para a captura ofertamos o benefício de processamento, onde utilizamos as seguintes tecnologias:

• Tipificação: indica qual o tipo de documento identificado

• Extração de dados (OCR): consiste em extrair os dados do documento a partir de uma imagem;

• FaceMatch: consiste em comparar a face da selfie com a face do documento;

• CPF Match: consiste em procurar no documento informado um determinado CPF.

Assinatura eletrônica

Quando há a necessidade de utilizar a biometria para assinar um documento. Utilize a mesma forma de autenticação do usuário na jornada para finalizar a operação com a assinatura do contrato.

*A capacidade de assinatura eletrônica só está disponível no meio de integração by Unico em flows com outras capacidades. Veja mais na seção fluxos possíveis.

Retorno de similaridade da Serpro

O retorno de similaridade da Serpro não é uma capacidade nativa do IDCloud, mas sim uma funcionalidade adicional incorporada para atender a uma regulamentação da Dataprev, referente a operações de crédito consignado do INSS, voltadas para aposentados e pensionistas.

Dado que essas operações exigem obrigatoriamente o retorno de similaridade da Serpro, a plataforma IDCloud foi ajustada para incluir essa funcionalidade como uma opção no produto. Ao utilizar o recurso de similaridade da Serpro, a resposta da API será o score de similaridade encontrado.

• Quando a Serpro encontra a face, é devolvido em score de 0-100, como no exemplo abaixo:

"government": {
        "serpro": 93.0 //este score é um exemplo.
    }

• Quando a Serpro não encontra a face, é devolvido o score -1, como no exemplo abaixo:

"government": {
        "serpro":-1
    }

• Quando há algum erro na integração com a Serpro, é devolvido o score -2, como no exemplo abaixo:

"government": {
        "serpro":-2
    }

Para entender como você pode usar cada uma das capacidades, não deixe de acessar a seção "Meios de Integração" no link abaixo:

by Unico

Para empresas que desejam contar com um parceiro para gerenciar a experiência do usuário com melhores práticas e privacidade, além de contar com a facilidade na orquestração de fluxos com as capacidades da Unico e com a atualização automática de tecnologias, como os SDKs.

Com o by Unico, você terá um time de especialistas em segurança e melhores práticas de UX design para garantir a melhor conversão possível em sua operação. Pode ser utilizada de forma responsiva tanto no Desktop quanto no Mobile. Oferendo as seguintes possibilidades de uso:

Confira como é a experiência do usuário final com o by Unico na Mensageria, Webview e iFrame, respectivamente, nas abas abaixo:

by Client

Para empresas que desejam controlar a experiência dos usuários com frontend próprio, bem como a construção dos fluxos com as capacidades da Unico no backend junto às demais tecnologias e recursos utilizados para autenticação.

Com o by Client você tem a liberdade que precisa para criar e gerenciar a jornada do usuário final como preferir, aproveitando as capacidades da plataforma Unico IDCloud como julgar necessário.

Para utilizar interações server-to-server, é preciso solicitar a criação da conta de serviço com o gerente de projetos responsável pela sua empresa enviando os seguintes dados: nome da empresa, nome da aplicação, nome, e-mail e celular do responsável pela aplicação na empresa. É preciso criar contas diferentes para os ambientes de Homologação e Produção.

Após o recebimento desses dados, será criada uma conta de serviço responsável por autenticar a sua aplicação e enviaremos um e-mail para que seja gerado o par de chaves para a conta.

Uma credencial de conta de serviço inclui um nome único de conta, um identificador da empresa (Tenant ID) e ao menos um par de chaves (pública e privada). Ao final da geração das chaves, você recebe apenas a chave privada (arquivo .key.pem), bem como o payload que deve ser utilizado para montar o JWT. Este payload terá o seguinte formato:

Caso precise da chave pública para configurar em seu sistema, contate o gerente de projetos responsável por sua conta. Também é possível gerar uma chave pública através do comando openssl a seguir:

Os erros retornados na requisição podem ser identificados através dos códigos abaixo e possuem a seguinte estrutura:

Após a criação e configuração de uma conta de serviço, sua aplicação precisa completar as seguintes etapas:

1. Criar um JSON Web Token (JWT), que inclui cabeçalho, payload e assinatura;

2. Requisitar um token de acesso (AccessToken) da plataforma de autenticação OAuth2;

3. Tratar a resposta JSON que a plataforma de autenticação retornará.

Se na resposta estiver incluso um token de acesso, você poderá usá-lo para fazer requisições às APIs dos produtos da unico para os quais a conta de serviço possui permissão de acesso. (Se na resposta não estiver incluso um token de acesso, seu JWT e requisição de obtenção do token podem estar incorretos ou a conta de serviço pode não ter as permissões necessárias para acessar os recursos solicitados.)

O token de acesso gerado na requisição mencionada acima tem validade padrão de 3600 segundos, podendo variar de acordo com a configuração de segurança estabelecida para sua empresa. Quando o token de acesso expirar, sua aplicação deverá gerar um novo JWT, fazer a assinatura e requisitar um novo token de acesso na plataforma de autenticação.

1 - Criando o JWT

Um JWT é composto por três partes: um cabeçalho, um payload e uma assinatura. O cabeçalho e o payload são objetos JSON. Esses objetos JSON são serializados em UTF-8 e então codificados usando codificação Base64url¹. Esta codificação provê resliência contra alterações de codificação em casos de repetidas operações de codificação. O cabeçalho, o payload e a assinatura são concatenadas com um caractere de ponto final ..

Um JWT é composto da seguinte forma:

O texto base para a assinatura é composto pela seguinte forma:

1.1 - Formando o cabeçalho JWT

O cabeçalho consiste em dois campos que indicam o algorítimo de assinatura e o formato do token. Ambos os campos são obrigatórios e cada campo possui apenas um valor. Contas de serviço dependem do algorítimo RSA SHA-256 e do formato de token JWT. Como resultado, a representação JSON do cabeçalho se dá da seguinte forma:

A representação em Base64url se dá da seguinte forma:

1.2 - Formando o payload JWT

O payload JWT contém informações sobre o JWT, incluindo as permissões sendo requisitadas (scopes), a conta solicitando acesso, o emissor, o momento em que o token foi emitido e o tempo de vida do token. A maioria dos campos são obrigatórios. Assim como o cabeçalho JWT, o payload é um objeto JSON e é usado na composição da assinatura.

1.3 - Campos Obrigatórios

Os campos obrigatórios no JWT são mostrados na tabela abaixo. Eles podem aparecer em qualquer ordem dentro do payload.

Entenda como funciona a conversão para os campos de emissão (iat) e expiração (exp) do jwt, e veja também exemplos de utilização dos valores dos campos aqui. Além disso, o campo “iat” deve ser o horário atual no formato exigido e o “exp” deve respeitar a conta abaixo:

A representação dos campos JSON obrigatórios no payload do JWT se dá da seguinte forma:

1.4 - Calculando a assinatura

A especificação JSON Web Signature (JWS)² é a mecânica que guia o cálculo da assinatura para um JWT. O conteúdo de entrada para o cálculo da assinatura é o byte array do seguinte conteúdo:

O mesmo algoritmo sinalizado no cabeçalho do JWT precisa ser utilizado para o cálculo da assinatura. O único algorítimo de assinatura suportado pela plataforma de autenticação OAuth2 é o RSA usando SHA-256. Ele é expressado como RS256 no campo alg do cabeçaho do JWT.

Assine a representação UTF-8 do conteúdo de entrada utilizando SHA256withRSA (também conhecido como RSASSA-PKCS1-V1_5-SIGN com o hash SHA-256) com a chave privada que foi criada e associada à conta de serviço (arquivo .key.pem gerado pela solicitação recebida por e-mail). O conteúdo de saída será um byte array.

A assinatura precisará ser então codificada em Base64url. O cabeçalho, o payload e a assinatura deverão ser concatenadas com o caractere de ponto final .. O resultado é o JWT. Ele deve ser da seguinte forma:

A seguir está um exemplo de token JWT antes da codificação em Base64url:

Abaixo está um exemplo do JWT que foi assinado e está pronto para transmissão:

Após a geração do JWT assinado, uma aplicação pode utilizá-lo para requisitar um token de acesso (Access Token). A requisição do token de acesso é uma requisição POST HTTPS e o corpo deve ser URL encoded. A URL é a mostrada abaixo:

Os parâmetros abaixo são obrigatórios na requisição POST HTTPS:

Se o JWT e a requisição do token de acesso foram formados apropriadamente e a conta de serviço tem as permissões necessárias, então a resposta da plataforma de autenticação retorna um objeto JSON contendo um token de acesso. Segue um exemplo de resposta da plataforma:

A duração do token de acesso é variável. Sua duração é especificada no campo “expires_in”, retornado juntamente com o token de acesso. Deve-se utilizar o mesmo token de acesso durante a sua validade para todas as chamdas às APIs dos produtos.

Não solicite um novo token de acesso até que a validade do token atual esteja chegando ao fim. Sugerimos uma margem de 600 segundos (10 minutos). Para isso execute o cálculo:

Sendo que token.exp é o timestamp da expiração do token.

Exemplos:

Um novo token de acesso pode ser solicitado quando faltar 10 minutos pra expirar.

• ¹ De acordo com o RFC 4648 de codificação BaseN, o formato Base64url é similar ao formato Base64, com exceção do caracter = que deve ser omitido, e dos caracteres + e / que devem ser substituídospor - e _, respectivamente.

Requisições separadas por flows

Outras formas de fazer uma requisição (request)

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint de Consulta do Resultado de Processos no by Unico.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Consulta do Resultado do Processo

O conteúdo retornado no parâmetro process.services.documents.doc.data, referente à tecnologia de OCR Extração, pode ser consultado abaixo:

Faça download do arquivo abaixo, importe no Postman e substitua o valor dos parâmetros "service_account", "tenant_id" e "secret_key" para testar a chamada.

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint de Obtenção do Conjunto Probatório do Documento Assinado no by Unico. Este endpoint fornecerá o conjunto probatório da assinatura do usuário final em fluxos que possuem a capacidade Assinatura Eletrônica.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Obtenção do Conjunto Probatório do Documento Assinado

Exemplo de um documento gerado:

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint de Obtenção da Selfie do Usuário no by Unico. Este endpoint fornecerá a selfie, com marca d'água, do usuário final em processos concluídos, permitindo que você a utilize como suporte em casos de contestação por parte do usuário.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Obtenção da Selfie do Usuário

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint de Obtenção do Conjunto Probatório no by Unico. Este endpoint fornecerá o conjunto probatório da transação biométrica finalizada, permitindo que você o armazene para possíveis contestações futuras por parte do usuário final.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Obtenção do Conjunto Probatório

Os seguintes exemplos de projetos são disponibilizados para facilitar o entendimento do funcionamento do by Unico.

PoCs em ambiente nativo

PoCs em ambiente web

O by Unico disponibiliza a funcionalidade de QR code para facilitar o fluxo em dispositivos desktop. Através do QR code, é possível iniciar o By Unico em uma experiência web sem ter que se preocupar se o dispositivo do usuário possui câmera ou não. Dessa forma:

• Diminuímos a chance de falha na captura biométrica;

• Garantimos uma melhor experiência em outras capacidades;

• Aumentamos as chances de conversão.

Quando o usuário inicia o By Unico através de um dispositivo desktop:

Identificamos que é um dispositivo desktop e oferecemos o QR code para possa continuar a jornada pelo celular:

Uma vez escaneado, o usuário segue sua jornada no celular normalmente, enquanto o dispositivo desktop aguarda sua conclusão:

O dispositivo desktop identifica que a jornada foi concluída no celular e redireciona o usuário para a experiência de origem:

O usuário pode continuar sua jornada na experiência de origem no desktop normalmente:

Critérios de qualificação do dispositivo como desktop

• Tamanho da tela: mínimo de 961px de largura;

• Orientação da tela: paisagem;

• User-Agent: não ser um dispositivo móvel.

Introdução

O by Client é um canal que oferece toda a liberdade para o cliente utilizar as soluções de validação de identidade da plataforma IDCloud.

Você pode combinar as capacidades como quiser e nos casos de uso mais distintos, mas para isso você deverá ter API Keys configuradas com as capacidades que deseja utilizar.

Capacidades síncronas e assíncronas

No by Client possuímos capacidades onde a resposta é síncrona (ou seja, no momento de criar o processo já devolvemos a resposta) e outras capacidades assíncronas (onde processamos os dados e você necessariamente precisa "buscar" este resultado através de um método GET na API REST.

Em sua operação você poderá combinar as capacidades como bem quiser, porém cada capacidade terá sua comunicação, por exemplo:

• Você pode ter uma operação que utilize as capacidades Verificação de Identidade + Alerta de comportamento + Score de risco;

• Ao criar o processo, a resposta das capacidades Verificação de Identidade e Alerta de comportamento serão síncronas, no próprio response da API de criação de processo;

• Já a capacidade de Score de risco será executada de forma assíncrona, sendo necessário aguardar seu processamento e então realizar uma outra requisição GET para obter o resultado final do processo.

Abaixo veja as capacidades síncronas e assíncronas:

Capacidades síncronas

Prova de vida:

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "liveness": 1
}

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "liveness": 2
}

Verificação de Identidade:

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "unicoId": {
    "result": "yes"
  }
}

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "unicoId": {
    "result": "no"
  }
}

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "unicoId": {
    "result": "inconclusive"
  }
}

Alerta de comportamento:

{
  "id": "2b034568-dfaf-463f-94fb-18ed93c312e8",
  "status": 3,
  "unicoId": {
    "result": "inconclusive"
  },
  "liveness": 1,
  "identityFraudsters": {
    "result": "yes"
  },
  "faceWithOtherId": {
    "result":"yes"
  }
}

{
  "id": "2b034568-dfaf-463f-94fb-18ed93c312e8",
  "status": 3,
  "unicoId": {
    "result": "inconclusive"
  },
  "liveness": 1,
  "identityFraudsters": {
    "result": "inconclusive"
}

Validação (1:1)

{
    "authenticated": "true"
}

{
    "authenticated": "false"
}

Reaproveitamento e captura de documentos:

{
  "id": "2b034568-dfaf-463f-94fb-18ed93c312e8",
  "status": 3,
  "document": {
    "id": "b97c3fd9-d95d-413f-bc0a-75eb87304421",
    "type": "CNH",
    "cpfMatch": false,
    "faceMatch": false,
    "content": {
      "numero": "044589731564",
      "rgNumero": "123456789 SESP PR",
      "nomeCivil": "Homer Simpson",
      "filiacao": [
        "Monasimpson",
        "Monasimpson"
      ],
      "dataNascimento": "1990-05-12T00:00:00Z",
      "dataHabilitacao": "1997-11-18T00:00:00Z",
      "dataExpiracao": "2017-12-07T00:00:00Z",
      "dataEmissao": "2012-12-07T00:00:00Z",
      "localEmissao": "Curitiba PR",
      "categoria": "B",
      "renachNumero": "PR904987581"
    },
    "fileUrls": [
      "https://url-signer-1",
      "https://url-signer-2"
    ]
  }
}

Capacidades assíncronas

Verificação de Identidade:

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "unicoId": {
    "result": "yes"
  }
}

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "unicoId": {
    "result": "no"
  }
}

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "unicoId": {
    "result": "inconclusive"
  }
}

Score de risco:

{
  "id": "2b034568-dfaf-463f-94fb-18ed93c312e8",
  "status": 3,
  "unicoId": {
    "result": "inconclusive"
  },
  "liveness": 1,
  "score": 50
}

Alerta de comportamento:

{
  "id": "2b034568-dfaf-463f-94fb-18ed93c312e8",
  "status": 3,
  "unicoId": {
    "result": "inconclusive"
  },
  "liveness": 1,
  "identityFraudsters": {
    "result": "yes"
  },
  "faceWithOtherId": {
    "result":"yes"
  }
}

{
  "id": "2b034568-dfaf-463f-94fb-18ed93c312e8",
  "status": 3,
  "unicoId": {
    "result": "inconclusive"
  },
  "liveness": 1,
  "identityFraudsters": {
    "result": "inconclusive"
}

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint relacionado à capacidade Prova de vida, utilizada de forma isolada.

Trata-se de uma capacidade síncrona, ou seja, toda a integração ocorre utilizando um único endpoint.

As capacidades da plataforma Unico IDCloud via by Client são gerenciadas por meio de API Keys - utilizadas como um parâmetro no header das requisições -, que definem o escopo de acesso. Como pré-requisito, é necessário possuir uma API Key configurada exclusivamente para a capacidade Prova de Vida, garantindo acesso dedicado e seguro ao recurso.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Criação do Processo

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint relacionado às capacidades Prova de Vida + Verificação de Identidade, utilizadas em conjunto.

Trata-se de duas capacidades síncronas, ou seja, toda a integração ocorre utilizando um único endpoint.

As capacidades da plataforma Unico IDCloud via by Client são gerenciadas por meio de API Keys - utilizadas como um parâmetro no header das requisições -, que definem o escopo de acesso. Como pré-requisito, é necessário possuir uma API Key configurada com as capacidades Prova de Vida + Verificação de Identidade, garantindo acesso dedicado e seguro ao recurso.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Criação do Processo

Introdução

O by Unico é um canal que oferece uma infraestrutura de soluções de validação de identidade da plataforma IDCloud.

Tem por objetivo, simplificar o uso das capacidades da plataforma IDCloud oferecendo uma solução que pode ser integrada ao seu back-end e front-end e que aumenta a segurança das transações.

Dispositivos compatíveis

Web

Compatível com todos os dispositivos com câmera frontal, seja em laptops ou mobile, respeitando a lista de navegadores oficialmente suportados abaixo:

Fluxos possíveis

Para isso, você irá mudar apenas o parâmetro flow no payload da REST API, e com isso terá diversas possibilidades de jornadas de verificação. Verifique abaixo a tabela relacionando os flows disponíveis e suas respectivas capacidades:

Fluxos depreciados

Como integrar

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint relacionado às capacidades Prova de Vida + Validação (1:1), utilizadas em conjunto.

Trata-se de duas capacidades síncronas, ou seja, toda a integração ocorre utilizando um único endpoint.

As capacidades da plataforma Unico IDCloud via by Client são gerenciadas por meio de API Keys - utilizadas como um parâmetro no header das requisições -, que definem o escopo de acesso. Como pré-requisito, é necessário possuir uma API Key configurada com as capacidades Prova de Vida + Validação (1:1), garantindo acesso dedicado e seguro ao recurso.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Criação do Processo

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento dos endpoints relacionado às capacidades Prova de Vida + Verificação de Identidade + Score de risco, utilizadas em conjunto.

Trata-se de duas capacidades síncronas (Prova de vida + Verificação de Identidade) integradas com uma capacidade assíncrona (Score de risco). Ou seja, enquanto a maior parte dos processos retornará respostas síncronas, uma parte deles será orquestrada com o Score de risco e precisarão ser consultados posteriormente.

Para essa integração, será necessário consumir dois endpoints descritos nesta documentação, que também podem ser combinados com o uso de Webhooks.

As capacidades da plataforma Unico IDCloud via by Client são gerenciadas por meio de API Keys - utilizadas como um parâmetro no header das requisições -, que definem o escopo de acesso. Como pré-requisito, é necessário possuir uma API Key configurada com as capacidades Prova de Vida + Verificação de Identidade + Score de risco, garantindo acesso dedicado e seguro ao recurso.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Criação do Processo

Consulta do Resultado do Processo

No endpoint da v2 (/processes/v2/{id}), também devolvemos algumas informações adicionais do usuário, conforme exemplo abaixo:

"processAdditionalInfo": {
      "transactionId": "2ed76ac5-8fd7-4477-839d-92bedd7e9fd5",
      "personName": "Nome da pessoa",
      "personDocument": "Número do documento da pessoa",
      "personImage": "URL assinada da imagem da pessoa",
      "finishedAt": "2024-10-04T18:53:17.028228"
  }
}

Para utilizar a plataforma IDCloud é necessário se autenticar via token de acesso, utilizando o sistema de autenticação conhecido como OAuth2.

O sistema de autenticação OAuth2 da unico suporta a interação server-to-server entre uma aplicação web e os serviços da unico.

Para este cenário, você precisará de uma conta de serviço, que é uma conta impessoal que pertence à sua aplicação e não a um usuário individual. Sua aplicação chama as APIs da unico em nome da conta de serviço, portanto usuários não estão diretamente envolvidos. Este cenário é chamado “two-legged OAuth”, ou “2LO”. Tipicamente, uma aplicação utiliza uma conta de serviço quando a aplicação chama as APIs da unico para trabalhar com seus próprios dados ao invés dos dados do usuário.

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento do endpoint de Criação de Processos no by Unico. Perceba que, para utilizar as capacidades da plataforma IDCloud neste meio de integração, basta alterar o valor do parâmetro "flow" no momento de criar o processo e a Unico será a responsável por orquestrar todas as capacidades que deseja utilizar.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Criação do Processo

Introdução

Nesta seção, você encontrará a documentação detalhada sobre o funcionamento dos endpoints relacionados à capacidade Reaproveitamento e captura de documentos. O uso do Reaproveitamento exige que haja um processo de Verificação de Identidade anterior e este deve obtido a resposta "SIM" OU um Score de risco igual ou maior que +50, do contrário será necessário capturar o documento do usuário.

Trata-se de uma capacidade síncrona que exige o consumo de dois endpoints, detalhados nesta documentação, para sua utilização completa.

As capacidades da plataforma Unico IDCloud via by Client são gerenciadas por meio de API Keys - utilizadas como um parâmetro no header das requisições -, que definem o escopo de acesso. Como pré-requisito, é necessário possuir uma API Key configurada excluvisamente para a capacidade Reaproveitamento e captura de documentos, garantindo acesso dedicado e seguro ao recurso.

Antes de começar

Suas requisições de API são autenticadas utilizando um access-token. Qualquer requisição que não inclua um access-token válido retornará um erro.

Consulta de documento para ser reaproveitado

Criação do Processo

Conteúdo retornado no document.content baseado no document.type: