Reading a result

Every call you make appears in the Console under Results. This page explains what you are looking at, and how to answer the question that actually matters when something goes wrong: why did this decide the way it did?

Sessions and transactions

The list shows sessions, not individual calls. A session groups the calls that belong to one person’s attempt, so a liveness check, a face verification and a voice verification appear together rather than as three unrelated rows.

Expanding a session shows the transactions inside it. Each transaction is one API call and carries its own decision.

What the outcomes mean

A transaction records a decision:

Decision	Meaning
pass	The check succeeded
fail	The check ran and did not succeed
refer	Neither — something needs a human to look at it
enrolled	The call created a biometric template rather than checking one

refer is not a failure. It means the result fell in a band your scoring system treats as inconclusive, or something about the attempt — several devices, several locations — warrants review. Treating it as a rejection makes your integration stricter than you configured it to be.

A session then carries an outcome, computed from its transactions: success if everything passed, fail if any transaction failed, refer if anything asks for review.

The session outcome is computed by the Console

It is not a field the API returns. If you derive your own session-level verdict from the transactions, you may legitimately reach a different answer than the Console shows — neither is wrong, they are different rules. When you need one authoritative answer, use the transaction decisions, which the backend records.

Why a verification decided what it did

Open a transaction to see the services that ran and what each returned.

The scoring breakdown is the part worth understanding. Each service returns a score, and your scoring system decides what that score means.

Scores are on a 0–100 scale, and for voice and face verification 50 is the provider’s own acceptance threshold — at or above 50 the engine accepted the person, below 50 it rejected them. That anchoring matters: it makes the number comparable between users, which the provider’s raw score is not, because the engine calibrates per enrolled template.

The transaction also records which version of your scoring system judged it. Changing a threshold creates a new version rather than editing the old one, so an old transaction always means what it meant at the time.