Inyo360 — Identity Verification (KYC)

The Identity Verification API is part of the Inyo360 compliance suite — a new identity-verification technology built in-house by Inyo. It combines machine learning and agentic AI with advanced computer vision to perform robust KYC verification, rather than relying on a third-party vendor.

Welcome screen — ID verification then face verification, about a minute Choosing a document type — passport, driver's license, or identity card Prepare screen — what will be captured before the camera opens Capturing a passport photo page, with the machine-readable zone inside the guide Taking a selfie, face centred in the oval

Checking liveness and matching the face against the document portrait

Approved — identity confirmed

Device & Signal Risk

Document Authenticity

Liveness & Face match

Coherence Checks

Sanctions Screening

Approved

The customer photographs a government-issued document — passport, driver's license, or identity card — and takes a selfie. Inyo extracts the document data, validates it, checks that the document is authentic and unexpired, confirms the selfie is a live person, and matches that person against the document portrait. Agentic AI orchestrates these checks and adjudicates borderline cases, so you receive a single normalized decision: approved, declined, or in_review.

How It Works

sequenceDiagram
    autonumber
    participant Y as Your System
    participant I as Inyo
    participant C as Customer
    Y->>I: POST /v1/sessions
    I-->>Y: sessionId +<br/>widgetUrl
    Y->>C: deliver widgetUrl
    C->>I: document<br/>front / back
    C->>I: selfie + liveness
    Note over I: Run verification<br/>checks
    I-->>Y: signed webhook<br/>or redirect
    Y->>I: GET /v1/sessions/{id}
    I-->>Y: approved /<br/>declined /<br/>in_review
    Y->>C: show outcome

Two Ways to Integrate

Choose one per verification — both produce the same normalized result and honor the same configuration.

Mode	How it works	Choose this when
Hosted widget	You create a session and receive a `widgetUrl`. Send it to your customer or open it in a webview. Inyo handles camera capture, framing guidance, retries, and localization.	You want the fastest integration and no camera code of your own. This is the recommended default.
Server-to-server	You capture the images yourself and post them to `POST /v1/verifications`. The result comes back in the response.	You already have a capture UI, or verification happens without a live customer (for example, re-verifying stored documents).

Integration Steps

Step	Action	Endpoint	Description
1	Authenticate	`POST /oauth/token`	Exchange your client credentials for a Bearer token
2	Create a session	`POST /v1/sessions`	Returns a `sessionId` and a `widgetUrl`
3	Deliver the widget	—	Send the link, or open it in a webview
4	Receive the result	your `webhookUrl`	A signed `POST` of the verification result
5	Read the decision	—	Interpret `status`, `autoStatus`, and `checks[]`
6	Confirm server-side	`GET /v1/sessions/{sessionId}`	The authoritative record, for polling or reconciliation

Skipping the widget? Replace steps 2-4 with a single server-to-server verification.

What You Receive

Every verification resolves to one normalized result containing the decision, the extracted document and person data, and the individual checks that produced the decision:

{
  "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"
}

The full payload and the rules for reading it are on Checks & Decisions.

Architecture Pattern

Your OAuth credentials are server-side only. Create sessions from your backend and hand the customer only the returned widgetUrl — it carries a single-use, time-limited code and grants access to nothing but that one verification.

flowchart TB
    subgraph browser["Customer's device"]
        C["Browser /<br/>webview"]
    end
    subgraph yours["Your infrastructure"]
        S["Your server<br/>holds OAuth credentials"]
    end
    subgraph inyo["Inyo"]
        W["Hosted widget"]
        A["Tenant API"]
    end
    S -->|"POST /v1/sessions<br/>Bearer token"| A
    A -->|"widgetUrl"| S
    S -->|"widgetUrl only"| C
    C -->|"document + selfie"| W
    W --> A
    A -->|"signed result"| S

Environments

Resource	URL
Tenant API (sandbox)	`https://{FQDN}`
Tenant API (production)	`https://{FQDN}`
Widget host	`https://{FQDN}`

Base URLs, OAuth client credentials, and IP allowlisting are issued by Inyo during onboarding. Sandbox and production credentials are not interchangeable.

Next Steps

Page	What it covers
Getting Started	Run one verification end to end
Authentication	Tokens, scopes, and error handling
Verification Sessions	Every field on `POST /v1/sessions`
Receiving Results	Signature verification and delivery modes
Manual Review	Handling `in_review` correctly
Sandbox & Test Data	Testing before you go live