It integrates with anything, because it is two HTTP calls.

There is no partner directory on this page, and we are not going to print one. What there is instead is the whole integration surface, listed and filterable: a transport, a URL, a way to be told the answer, and native SDKs for the teams that want them.

The whole server side, in full.

Not an excerpt. Two calls and one URL is the entire contract between your backend and ours, and the second call is optional if you take the webhook instead.

Create a session, then send the person to the URL

POST /v1/verification-sessions
  -> { "session_id": "...", "url": "https://..." }

GET  /v1/verification-sessions/{session_id}
  -> { "verified": true, "meets_age": true, … }

Illustrative shape. The real paths, field sets and token handling are in the API reference.

What each surface is for
SurfaceYou use it when
hosted URLYou would rather not build, ship or audit a capture flow inside your app.
webhookYour backend can accept an inbound request, and you want the result pushed.
result fetchYour backend cannot accept inbound requests, so you read the result instead.
native SDKThe capture has to live inside your own app, on React Native or Flutter.

The directory.

Filter by what you are actually deciding: how the call is carried, how you are told the answer, what the client runs on, and whether you have a backend at all.

Filter

  • REST, server to serverHTTP + JSON

    Two calls. Your server creates a verification session and reads the result. There is no SDK to install on the server side and no client library to keep current, so the language your product is written in stops being a gating question — anything that can post JSON over TLS is already integrated.

  • Hosted verification URLredirect

    The session you create returns one URL. You send the person to it and they come back. The capture, the chip read, the trust-chain check and the deletion all happen on our side of that URL, which means none of it has to be built, shipped or audited inside your app.

  • Signed webhooksPOST, signed

    The result is pushed to an endpoint you own, signed so you can prove it came from us and reject a replay. Use this when the person’s return trip through the browser is not a trustworthy place to learn the verdict — which it never is.

  • Server-side result fetchGET

    The alternative to a webhook, for a backend that cannot accept inbound requests: read the result yourself when the person returns. Same payload, same field set, and the verdict still never travels through the client.

  • React Native SDKnative module

    A verification SDK for apps already built in React Native, for teams that want the capture inside their own app rather than behind a hosted URL. It buys you the native camera and chip paths; it does not change the two server calls behind it.

  • Flutter SDKplugin

    The same verification surface for Flutter apps. Both SDKs are a convenience over the hosted URL, not a dependency: a client that never installs either one is fully integrated.

  • iOS, with App AttestApp Attest

    On iOS the capture carries Apple App Attest, which proves the request came from a genuine unmodified build of the app on real Apple hardware. Each capture is also hashed and signed on the device with a single-use nonce, so frames cannot be swapped in or replayed afterwards.

  • Androidnative app

    The Android app runs the same capture, chip read and on-device capture manifest. Stated plainly, because the asymmetry matters to anyone reading this properly: hardware attestation is not configured on Android, so an Android capture is not the equivalent of an attested iOS one.

  • Serverless functions for a static frontendtwo functions

    A static site with no backend of its own still has somewhere to put two small functions — one to create the session, one to receive the result or the webhook. That is the entire server side. The client token stays in the function, which is the only place it belongs.

  • SSO / OIDC / Entraroadmap

    Verification as an identity provider, so an enterprise can place JERIX in front of an existing sign-in. The signing core this needs is shipped and running.

    Not shippedThe four endpoints do not exist yet. Blocked on building them.

No logo wall, no partner tiles, no marketplace listings. The company is two founders with one third-party integration live since 30 August 2026 and a second in progress, and the client is a gaming ticket platform we do not name. A directory of invented partners would be the first thing a security officer caught.

What a client actually has to hold.

You choose the field set, and the smallest one is genuinely small. The integration running in production today receives three fields and nothing else: no name, no national ID number, no date of birth, no image. It holds nothing identifying, so it has nothing to leak.

Tokens are isolated per client. Two platforms that both verify the same person receive different tokens and cannot cross-reference their user bases — which also means the integration cannot be turned into a data-sharing arrangement later.

The quickstart, end to end →

The smallest useful payload

{
  "verified":     true,
  "meets_age":    true,
  "age_gate_min": 18
}

Illustrative shape. Larger field sets exist and are configured per client.

Twenty minutes to see the integration end to end.

A real passport, the trust chain resolving offline, and the two calls run in front of you.

Request a walkthrough