Inyo360 — Verificação de Identidade (KYC)

A API de Verificação de Identidade faz parte da suíte de conformidade Inyo360 — uma nova tecnologia de verificação de identidade desenvolvida internamente pela Inyo. Ela combina machine learning e IA agêntica com técnicas avançadas de visão computacional para realizar uma verificação KYC robusta, em vez de depender de um fornecedor terceirizado.

O cliente fotografa um documento emitido pelo governo — passaporte, carteira de motorista ou carteira de identidade — e tira uma selfie. A Inyo extrai os dados do documento, valida-os, verifica se o documento é autêntico e não está vencido, confirma que a selfie é de uma pessoa real e compara essa pessoa com o retrato do documento. A IA agêntica orquestra essas verificações e decide os casos limítrofes, de modo que você recebe uma única decisão normalizada: approved, declined ou in_review.

Como Funciona

sequenceDiagram
    autonumber
    participant Y as Seu Sistema
    participant I as Inyo
    participant C as Cliente
    Y->>I: POST /v1/sessions
    I-->>Y: sessionId +<br/>widgetUrl
    Y->>C: entrega o widgetUrl
    C->>I: documento<br/>frente / verso
    C->>I: selfie + prova de vida
    Note over I: Executa<br/>verificações
    I-->>Y: webhook assinado<br/>ou redirecionamento
    Y->>I: GET /v1/sessions/{id}
    I-->>Y: approved /<br/>declined /<br/>in_review
    Y->>C: mostra o resultado

Duas Formas de Integrar

Escolha uma por verificação — ambas produzem o mesmo resultado normalizado e respeitam a mesma configuração.

Etapas de Integração

Vai pular o widget? Substitua as etapas 2-4 por uma única verificação server-to-server.

O Que Você Recebe

Cada verificação resulta em um único resultado normalizado contendo a decisão, os dados extraídos do documento e da pessoa, e as verificações individuais que produziram a decisão:

{
  "sessionId": "…",
  "userRef": "user-123",
  "status": "approved",
  "autoStatus": "approved",
  "document": { "type": "passport", "number": "…", "expirationDate": "2033-09-30" },
  "person": { "firstName": "…", "lastName": "…", "dateOfBirth": "1988-03-04" },
  "checks": [
    { "name": "document_not_expired", "status": "passed", "group": "document", "detail": "…" },
    { "name": "face_match", "status": "passed", "group": "selfie", "detail": "similarity vs threshold 90.0" }
  ],
  "provider": "inyo"
}

O payload completo e as regras para interpretá-lo estão em Verificações e Decisões.

Padrão de Arquitetura

Suas credenciais OAuth são exclusivas do servidor. Crie sessões a partir do seu backend e entregue ao cliente apenas o widgetUrl retornado — ele carrega um código de uso único e com prazo limitado, e não concede acesso a nada além daquela única verificação.

flowchart TB
    subgraph browser["Dispositivo do cliente"]
        C["Navegador /<br/>webview"]
    end
    subgraph yours["Sua infraestrutura"]
        S["Seu servidor<br/>guarda as credenciais OAuth"]
    end
    subgraph inyo["Inyo"]
        W["Widget hospedado"]
        A["API do tenant"]
    end
    S -->|"POST /v1/sessions<br/>token Bearer"| A
    A -->|"widgetUrl"| S
    S -->|"apenas o widgetUrl"| C
    C -->|"documento + selfie"| W
    W --> A
    A -->|"resultado assinado"| S

Ambientes

As URLs base, as credenciais de cliente OAuth e a lista de IPs permitidos são emitidas pela Inyo durante o onboarding. As credenciais de sandbox e produção não são intercambiáveis.

Próximos Passos