Read a session's result
GET /api/verification/:sessionId/result — the authenticated, boolean-only verdict your server acts on, and why it returns no personal data.
Last updated: 2026-09-04
Returns the verdict for a session to the merchant that owns it. This is the authoritative read: the one your server calls, and the one your business logic branches on.
GET https://api.eidas-pro.com/api/verification/{sessionId}/result
Requires the x-merchant-api-key header — see authentication.
Request
curl https://api.eidas-pro.com/api/verification/0f3c1c2b-9a4d-4d1f-8c1a-2b6d5e4f7a90/result \
-H "x-merchant-api-key: YOUR_API_KEY"
Response
{
"status": "verified",
"verified": true,
"thresholdMet": true
}
Three fields, and there will never be a fourth carrying personal data:
| Field | Type | Notes |
|---|---|---|
status | string | The session state: pending, scanned, verified, rejected, or expired. |
verified | boolean | Did the check pass? This is the field to gate on. |
thresholdMet | boolean | Was the requested threshold satisfied? Today it is derived from the same terminal state as verified, so the two always agree. |
A non-terminal status means the shopper has not finished yet — that is not a failure, and it is not a verified: false you should act on. Wait for verified, rejected, or expired before you let the answer decide anything.
What it deliberately does not return
A pass/fail signal, not an identity record
The response contract for this endpoint carries no personal data by construction — no date of birth, no age value, no country code, no name, no document number, no address. Not "redacted", not "available on request": the shape has three fields and none of them is an attribute. A merchant learns whether the shopper passed the check it asked for, and nothing else about who the shopper is.
This is the point of routing a check through electronic identity rather than asking for a document upload. If you are migrating from a provider that returned a date of birth or a country code, there is no equivalent field to map to — the equivalent is verified, and the parts of your code that stored an attribute should stop.
Ownership, and why a foreign session is a 404
The session id travels through the shopper's browser as part of the redirect flow, so it is not a secret between two servers. This endpoint therefore checks that the session belongs to the merchant whose key made the request.
A session that belongs to another merchant answers 404 NOT_FOUND — the same response as a session id that was never issued. That is deliberate: a 403 would confirm the session exists, which is exactly what a caller holding someone else's id should not learn. It also means a 404 here does not always mean "no such session"; it can mean "not yours".
Failures
| Status | code | Cause |
|---|---|---|
401 | INVALID_MERCHANT_KEY | Key missing, unknown, revoked, or expired — one identical response for all. |
404 | NOT_FOUND | No such session, a session that belongs to another merchant, or one that has expired and been swept. |
429 | RATE_LIMIT_EXCEEDED | 600 requests per minute, counted per merchant rather than per IP address. |
The 429 ceiling is set per merchant so that shops sharing an egress IP address do not share a bucket, and it is high enough to carry roughly twenty concurrent shoppers polling every two seconds. If you are hitting it, poll less often per shopper rather than spreading the same rate across more addresses. See errors and status codes for the envelope shape and the Retry-After header.