---
description: >-
  Inyo Identity Verification (KYC) API — verify a customer's government ID and selfie through a hosted widget or a server-to-server call, and receive a signed approved/declined/in_review decision by webhook or redirect.
---

# 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.

<div class="kyc-hero">
<div class="kyc-phone">
<div class="kyc-screens">

![Welcome screen — ID verification then face verification, about a minute](/images/kyc/01-welcome.webp) ![Choosing a document type — passport, driver's license, or identity card](/images/kyc/02-doctype.webp) ![Prepare screen — what will be captured before the camera opens](/images/kyc/03-prepare.webp) ![Capturing a passport photo page, with the machine-readable zone inside the guide](/images/kyc/04-capture-front.webp) ![Taking a selfie, face centred in the oval](/images/kyc/06-selfie.webp)

<div class="kyc-checking">

![Checking liveness and matching the face against the document portrait](/images/kyc/07-analyzing-plate.webp)

</div>

![Approved — identity confirmed](/images/kyc/08-result-approved.webp)

</div>
</div>
<div class="kyc-checks">
<div class="kyc-check c1">Device &amp; Signal Risk</div>
<div class="kyc-check c2">Document Authenticity</div>
<div class="kyc-check c3">Liveness &amp; Face match</div>
<div class="kyc-check c4">Coherence Checks</div>
<div class="kyc-check c5">Sanctions Screening</div>
<div class="kyc-verdict">Approved</div>
</div>
</div>

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

```mermaid
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](authentication.md) | `POST /oauth/token` | Exchange your client credentials for a Bearer token |
| 2 | [Create a session](sessions.md) | `POST /v1/sessions` | Returns a `sessionId` and a `widgetUrl` |
| 3 | [Deliver the widget](widget-delivery.md) | — | Send the link, or open it in a webview |
| 4 | [Receive the result](results.md) | your `webhookUrl` | A signed `POST` of the verification result |
| 5 | [Read the decision](checks-and-decisions.md) | — | Interpret `status`, `autoStatus`, and `checks[]` |
| 6 | [Confirm server-side](sessions.md#retrieve-a-session) | `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](server-to-server.md).

***

### 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:

```json
{
  "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](checks-and-decisions.md).

***

### 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.

```mermaid
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](getting-started.md) | Run one verification end to end |
| [Authentication](authentication.md) | Tokens, scopes, and error handling |
| [Verification Sessions](sessions.md) | Every field on `POST /v1/sessions` |
| [Receiving Results](results.md) | Signature verification and delivery modes |
| [Manual Review](manual-review.md) | Handling `in_review` correctly |
| [Sandbox & Test Data](sandbox-and-test-data.md) | Testing before you go live |