Inyo360 — Identity Verification (KYC)

The Identity Verification API, part of the Inyo360 compliance suite, confirms that a customer is who they claim to be. 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. You receive a single normalized decision: approved, declined, or in_review.

How It Works

┌──────────────┐   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│   Create     │   │   Customer   │   │   Document   │   │  Selfie +    │
│   Session    │──▶│   Opens the  │──▶│   Capture    │──▶│  Liveness    │
│  (your API)  │   │   Widget     │   │  (front/back)│   │  Face Match  │
└──────────────┘   └──────────────┘   └──────────────┘   └──────────────┘
                                                                │
      ┌──────────────┐   ┌──────────────┐   ┌──────────────┐    │
      │  Your System │   │   Signed     │   │   Decision   │◀───┘
      │   Updates    │◀──│  Webhook or  │◀──│  approved /  │
      │   the User   │   │   Redirect   │   │  declined /  │
      └──────────────┘   └──────────────┘   │  in_review   │
                                            └──────────────┘

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 `widget_url`. 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 `session_id` and a `widget_url`
3	Deliver the widget	—	Send the link, or open it in a webview
4	Receive the result	your `webhook_url`	A signed `POST` of the verification result
5	Read the decision	—	Interpret `status`, `auto_status`, and `checks[]`
6	Confirm server-side	`GET /v1/sessions/{session_id}`	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:

{
  "session_id": "…",
  "user_ref": "user-123",
  "status": "approved",
  "auto_status": "approved",
  "document": { "type": "Passport", "number": "…", "expiration_date": "2033-09-30" },
  "person": { "first_name": "…", "last_name": "…", "date_of_birth": "1988-03-04" },
  "checks": [
    { "name": "document_not_expired", "passed": true, "score": null, "detail": "…" },
    { "name": "face_match", "passed": true, "score": 98.7, "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 widget_url — it carries a single-use, time-limited code and grants access to nothing but that one verification.

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   Customer   │────▶│  Your Server │────▶│   Inyo KYC   │
│   Browser /  │     │  (holds the  │     │   Tenant API │
│   Webview    │◀────│  credentials)│◀────│              │
└──────────────┘     └──────────────┘     └──────────────┘
       │                                          ▲
       │            widget_url                    │
       └──────────────────────────────────────────┘
              customer talks only to the widget

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
Tenant Configuration	Thresholds, document types, and branding
Sandbox & Test Data	Testing before you go live