Dynamic link verification

Use your backend to mint a short-lived hosted link that opens the Sentinel verification portal for a specific customer. Your frontend opens that link, the customer completes liveness, document capture, and review on the portal, and status changes come back to you by webhook or polling. Your client secret never reaches the browser.

Architecture at a glance

Four actors are involved.

• Your backend holds clientUuid and clientSecret, calls POST /clients/encrypt/url, and forwards the returned URL to your frontend.
• Your frontend receives the URL and opens it. It never sees the secret.
• Sentinel validates your credentials, encrypts the payload, and serves the portal, the status endpoints, and webhook delivery.
• The hosted portal is the verification flow the customer actually uses, themed for your tenant.

Create the link

Mint the link from your backend so clientSecret never touches the browser. Send a POST with your credentials and, optionally, the customer's contact details and a document scope.

POST https://api.sentinel.example.com/clients/encrypt/url

Example request:

{
  "clientUuid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "clientSecret": "xxxxxxxxxxxxxxxx",
  "phoneNumber": "+971501234567",
  "email": "jane.doe@example.com",
  "documents": ["passport", "emiratesId"]
}

Response (200):

{
  "message": "Success",
  "data": "https://verify.sentinel.example.com?data=<encrypted-token>"
}

Documents

The optional documents array restricts which identity documents the customer can upload.

• passport: only passport upload is offered.
• emiratesId: only Emirates ID upload is offered.
• egyptNationalId: accepted by the API, but the portal does not render it yet.

Combinations are allowed, for example ["passport", "emiratesId"]. Omitting the field is equivalent to passing both passport and Emirates ID. You can also set a default document scope from your dashboard, so this field is optional for most integrations.

Wire up the flow

Expose a thin endpoint on your backend that calls Sentinel, then have your frontend call that endpoint and open the returned URL.

Your backend mints the URL on demand:

// Node / Express, using an HTTP client (for example axios)
app.post('/verification/link', async (req, res) => {
  const { phoneNumber, email } = req.body

  const response = await http.post(
    'https://api.sentinel.example.com/clients/encrypt/url',
    {
      clientUuid: process.env.SENTINEL_CLIENT_UUID,
      clientSecret: process.env.SENTINEL_CLIENT_SECRET,
      phoneNumber, // or email
    },
  )

  // The hosted link is in response.data.data
  res.json({ url: response.data.data })
})

Your frontend calls your backend, then opens the returned URL:

async function startVerification() {
  const { url } = await http.post('/verification/link', { phoneNumber })
  window.open(url, '_blank')
}

Redirect after completion

To send the customer somewhere after they finish, append &redirectUrl= with an absolute URL to the link your backend returned. HTTPS URLs and custom app schemes (deep links back into a mobile app) are both accepted. URL-encode the value if it carries query parameters of its own.

https://verify.sentinel.example.com?data=<encrypted-token>&redirectUrl=https://yourapp.example.com/verify/done

When the journey ends, the portal shows a brief confirmation for about five seconds, then performs a full-page navigation to your URL with a status query parameter appended. Query parameters already on your URL are preserved; a status parameter of your own would be overwritten.

https://yourapp.example.com/verify/done?status=success
yourapp://verify/done?status=failed

• status=success: the customer completed and submitted a verification in this session.
• status=failed: the journey ended without a new submission. This also covers an already-verified customer re-opening a link, so read it as "no new verification", not necessarily as a rejection.

The redirect target is remembered for the lifetime of the browser session, so it survives page reloads during the journey.

Per-client settings

The portal reads several settings on load and adapts. Some come from the encrypt request, others from your client configuration.

Default documents and modifiable identifiers are managed from your dashboard. Brand theme colors are not yet self-serve, so contact the Sentinel team to set them for your tenant.

Notes

• clientSecret is server-side only. Never embed it in frontend code, mobile app bundles, or query strings.
• The theme comes from your client configuration. Do not assume a fixed palette.
• Use the returned URL verbatim. The host can differ per client.