Inyo

Sessões de Verificação

Uma sessão representa uma verificação de identidade. Criá-la retorna uma widgetUrl que você entrega ao seu cliente e um sessionId que você usa para correlacionar o resultado.


Criar uma Sessão

Endpoint: POST /v1/sessions
Autenticação: Token Bearer com o escopo sessions

curl --request POST \
  --url https://{FQDN}/v1/sessions \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header 'Content-Type: application/json' \
  --data '{
  "userRef": "user-123",
  "language": "es",
  "delivery": { "mode": "webhook" }
}'
{
  "sessionId": "9f1c8e42-7c3e-4f2b-9d7a-2b1e5c8f4a10",
  "status": "pending",
  "widgetUrl": "https://{FQDN}/verify/8Kd2mQ…"
}

Campos da Requisição

CampoTipoObrigatórioDescrição
userRefstring (1-255)SimSeu identificador para a pessoa sendo verificada. Devolvido em todos os resultados
prefillobjectNãoDados conhecidos sobre a pessoa — veja Prefill
dataCheckbooleanNãofalse (padrão) verifica o documento conforme apresentado. true adicionalmente compara os dados extraídos com o prefill — veja Verificações de Dados
deliveryobjectNãoComo o resultado chega até você. O padrão é {"mode": "webhook"}
languagestringNãoIdioma do widget, xx ou xx-XX (ex.: en, pt, es, pt-BR). Recorre ao seu padrão configurado
maxCaptureAttemptsinteger (1-10)NãoSobrescreve o padrão do seu tenant apenas para esta sessão. Aplica-se por tipo de captura — este número de tentativas de documento e o mesmo de selfie

Campos da Resposta

CampoDescrição
sessionIdUse-o para correlacionar resultados e para chamar GET /v1/sessions/{sessionId}
statusSempre pending na criação
widgetUrlO link voltado ao cliente. Contém um código de uso único válido por 48 horas

Prefill

O prefill carrega o que você já sabe sobre a pessoa. Ele tem dois efeitos distintos.

CampoEfeito
documentTypepassport, drivers_license ou identity_card. Trava o widget neste documento — a tela de seleção de tipo é pulada, e um documento diferente é rejeitado. Omita-o para deixar o cliente escolher
documentNumberValidado quanto ao formato nesta chamada (veja abaixo) e disponível para verificação cruzada
issuingStateSomente a subdivisão — código ou nome de estado dos EUA. Refina a validação de formato de uma carteira. Não é um país: passaportes e carteiras de identidade não evidenciam subdivisão, então um alpha-3 enviado aqui ainda resolve a jurisdição, mas nunca é comparado com o documento. Informe o país em issuingCountry
issuingCountryISO 3166-1 alpha-3, um nome de país ou um alias comum. Nomeia o país emissor diretamente — uma carteira não o traz na face, então sem isso uma carteira não americana é verificada contra as tabelas dos EUA
nationalityISO 3166-1 alpha-3. Usado para resolver a jurisdição quando issuingState está ausente. Nunca usado para uma carteira — nacionalidade não é emissão
firstName, lastNameDisponíveis para verificação cruzada
dateOfBirthYYYY-MM-DD. Disponível para verificação cruzada
{
  "userRef": "user-123",
  "prefill": {
    "documentType": "drivers_license",
    "issuingState": "PA",
    "documentNumber": "31612967",
    "firstName": "Ana",
    "lastName": "Silva",
    "dateOfBirth": "1988-03-04"
  }
}

Campos de prefill diferentes de documentType não alteram a decisão a menos que você defina dataCheck: true. Sem isso, os valores são carregados para comparação e reportados no resultado, mas uma divergência não encaminha a sessão para lugar nenhum.

O prefill.documentNumber é validado nesta chamada, no entanto: um número que viola o formato conhecido de sua jurisdição é rejeitado com 422 em vez de ser aceito e reprovado depois. Verifique um número antes de chegar aqui com o endpoint validador.


Verificações de Dados

Defina dataCheck: true para verificar que o documento pertence à pessoa que você esperava — não apenas que o documento é genuíno.

{
  "userRef": "user-123",
  "dataCheck": true,
  "prefill": {
    "firstName": "Ana",
    "lastName": "Silva",
    "dateOfBirth": "1988-03-04"
  }
}

Com dataCheck: true:

  • Os dados extraídos são comparados campo a campo com o payload de prefill.
  • O resultado carrega prefillComparison (resultados por campo, incluindo pontuações de correspondência aproximada de nomes) e prefillMismatches (os nomes dos campos que divergiram).
  • Uma divergência adiciona uma checagem document_data_match reprovada e é reportada no resultado.

Nomes são comparados com correspondência aproximada (fuzzy) contra um limiar de similaridade configurável, então variações comuns de grafia e transliteração não criam falsas divergências. dataCheck: true sem um payload de prefill é um 422 — não haveria nada com que comparar.


Entrega

ModoCamposComportamento
webhook (padrão)O resultado é enviado via POST para a sua webhookUrl configurada
redirectredirectUrl (obrigatório)O cliente é retornado à sua URL com o resultado e uma assinatura
{ "delivery": { "mode": "redirect", "redirectUrl": "https://you.example/kyc-done" } }

Solicitar o modo webhook sem uma webhookUrl configurada para o seu tenant é um 422. Veja Recebendo Resultados para a verificação de assinatura em ambos os modos.


Respostas de Erro

Todas estas retornam 422 com errorCode: "validation_error"; errors[] nomeia o campo e a causa:

CausaNotas
delivery.mode é webhook mas nenhuma webhookUrl está configuradaPeça à Inyo para registrar seu endpoint, ou use o modo redirect
delivery.redirectUrl ausente no modo redirectObrigatório sempre que mode for redirect
documentType não está habilitado para o seu tenantA mensagem lista os tipos de documento que você pode solicitar
A jurisdição emissora do documento não é aceita para esse tipo de documentoA mensagem lista as jurisdições que você aceita
prefill.documentNumber falhou na validação de formatoA mensagem nomeia a regra que o rejeitou
dataCheck: true sem payload de prefillForneça pelo menos um campo de prefill comparável

Falhas de autenticação e autorização retornam 401 ou 403 — veja Autenticação.


Recuperar uma Sessão

Endpoint: GET /v1/sessions/{sessionId}
Autenticação: Token Bearer com o escopo sessions

Este é o registro autoritativo de uma sessão de widget. Leia-o quando você precisar de uma garantia em vez de um push, para recuperar um webhook que você pode ter perdido, ou para ler o resultado de uma sessão que foi para revisão manual.

Uma verificação criada com POST /v1/verifications não é servida aqui — ela tem uma leitura própria em GET /v1/verifications/{verificationId}, acessível com o scope verifications. Passar uma delas aqui retorna 404.

curl --request GET \
  --url https://{FQDN}/v1/sessions/$SESSION_ID \
  --header "Authorization: Bearer $ACCESS_TOKEN"
{
  "sessionId": "9f1c8e42-7c3e-4f2b-9d7a-2b1e5c8f4a10",
  "userRef": "user-123",
  "status": "completed",
  "step": "done",
  "deliveryMode": "webhook",
  "result": { "…": "the normalized result, updated in place" },
  "createdAt": "2026-07-31T14:02:11.481Z",
  "updatedAt": "2026-07-31T14:04:57.902Z"
}
CampoDescrição
statuspending, completed ou failed — a posição no ciclo de vida, nunca um veredito. O desfecho, quando você o recebe, é result.decision
stepAté onde o cliente chegou: document_front, document_back, selfie ou done
deliveryModewebhook ou redirect — como o desfecho desta sessão chega até você, escolhido na criação
resultO resultado normalizado completo quando disponível, null antes disso. Atualizado no lugar quando um analista decide

As sessões são estritamente limitadas ao tenant. O sessionId de outro tenant retorna 404 — nunca uma divulgação parcial.


Próximos Passos