Emnet documentation

Verify a person against Ethiopia’s national ID and receive verified claims — through three endpoints and, if you want it, two SDK calls.

What Emnet does

Emnet is a verification API. You start a verification, your user authenticates directly with Fayda (Ethiopia’s national ID service), and you receive a VerifiedIdentity: the claims you are entitled to, the assurance level of the authentication, liveness evidence where available, and provenance.

You never receive the person’s national identifier. Instead each verified person gets an identityKey — stable for your account so you can recognise a returning user, and unlinkable across other Emnet customers.

Emnet returns claims, never decisions

There is no KYC tier, approval flag or risk score in any response. Mapping a verification to a business outcome is your application’s job, and keeping it there is what allows your compliance evidence to live in your own systems. See Claims & identity keys.

The whole API

Endpoint	Purpose	Keys
`GET /v1/verification/person/fayda/authorize-url`	Start a verification and get the URL to send the user to	Secret or publishable
`POST /v1/verification/person/fayda/callback`	Exchange the returned code for verified claims	Secret only
`GET /v1/verification/person/session/{id}`	Read the status of a verification session	Secret or publishable

That is the entire public surface. Everything else — provider discovery, PKCE, signed client assertions, encrypted responses, key rotation — happens on our side.

Base URL

All requests

$EMNET_BASE_URL/v1

Your base URL is issued with your early-access key. There is no separate sandbox hostname. The environment is resolved from your API key on our servers: a test key reaches the provider’s sandbox, a live key reaches production. This is deliberate — an environment that can be chosen by a request parameter is an environment that can be chosen by mistake.

Start here

Quickstart

From an API key to a completed verification, end to end, in about fifteen minutes.

Authentication

Secret vs publishable keys, test vs live, and the rules that keep credentials safe.

Verification flow

The redirect flow in detail, including what to store between the two calls.

API reference

Every endpoint, parameter, response field and status code.

SDKs

The Java SDK is the officially supported client. It has no framework dependencies — java.net.http.HttpClient, Jackson and SLF4J only — so it drops into a Spring, Quarkus or plain-Java service without a dependency conflict.

Every endpoint is a plain JSON request over HTTPS, so any language works without an SDK. The API reference has curl examples for each call.

Conventions in these docs

Keys shown as sk_test_… and pk_test_… are illustrative. Yours are shown once, at creation.
All requests and responses are JSON, UTF-8, over HTTPS. HTTP is refused.
Timestamps are ISO-8601 in UTC (2026-07-26T09:14:22Z).
Unknown response fields are additive and safe to ignore — the SDKs already do. See our compatibility promise.

Getting help

Technical questions go to support@emnetid.com. Include the sessionId and the timestamp of a failing request — never your API key, and never a user’s personal data.