Core concepts

Sentinel has a small, stable vocabulary. Once you know how clients, customers, sessions, and results relate, every page in this documentation follows the same model.

The verification model

Your organization is a client. A client issues a verification session for a customer, the person you need to verify. During the session, Sentinel runs a set of checks and produces a result. The result is reflected by the customer's status, which your systems read through webhooks, the API, or the dashboard.

Clients

A client represents your organization within Sentinel. It carries the configuration that applies to every verification you run: which documents you accept, where webhooks are sent, and your re-verification policies. Your backend acts on behalf of a client using client credentials, covered in Authentication.

Customers

A customer is created the first time you verify a person, and the record persists across future verifications. This lets Sentinel recognize a returning person, track when their documents are due to expire, and keep a history of changes. Every customer is scoped to your client, so you only ever see your own customers.

Verification sessions

A session is a single attempt to verify a customer. Your backend requests a session and receives a hosted link, which the customer opens to complete the journey in their browser. Sentinel handles capture, validation, and screening inside the session, so you never handle raw biometric data yourself. Issuing and delivering sessions is covered in Dynamic link verification.

Supported documents

Sentinel verifies Emirates ID and international passports. A third type, Egyptian national ID, is accepted by the API but is not yet shown in the journey. Each client chooses which documents are accepted. See Dynamic link verification for the exact document values and behavior.

Checks performed

Every verification combines the same component checks into a single result.

The verification lifecycle

A verification runs from the moment it is initiated to a final outcome. Many resolve straight to Accepted or Rejected, while some pass through an intermediary review step first.

The stages and outcomes mean:

• Initiated: a verification session has been created for the customer.
• Pending: the customer has submitted, and Sentinel is verifying and screening the result.
• Accepted: the customer passed the checks.
• Rejected: the customer did not pass.

Conflict and Duplicate are intermediary. They hold a verification for review and are then resolved to Accepted or Rejected. Each is raised for a specific reason:

• Conflict: the submitted information does not reconcile, for example when the provided details and the document do not agree.
• Duplicate: the person matches an identity already present in your records.

A customer's status is not permanent. An operator can change it from the dashboard, for example to resolve a Conflict or Duplicate after review, or to overturn an automatic decision. See the Dashboard guide.

One more state covers re-verification. Draft means the customer needs to go through verification again. It is set automatically when a document expires, or from the dashboard when a verification should be redone, for example after a review or when document or liveness quality was poor. The customer is shown the reason when they reopen the link. Draft is described in Re-KYC and screening.

Screening concepts

Alongside identity checks, Sentinel screens each customer against global compliance sources. Two categories matter for integration:

• Sanctions and watchlists: checks against international sanctions and related watchlists.
• Politically exposed persons (PEP): flags individuals in prominent public positions who warrant additional diligence.

Screening contributes to the customer's outcome and can route a verification to review rather than an automatic decision. Screening can also run on an ongoing basis after a customer is accepted, covered in Re-KYC and screening.