Skip to main content
The widget fetches the request types and form fields that apply to your tenant and the subject’s jurisdiction, renders them, and submits the request. It is light and framework-free — pure DOM plus a scoped stylesheet, with no camera and no engine.

Pick a mode first

This single decision shapes the whole integration.
In authenticated mode the server binds the request to the session’s subject and ignores any identity fields posted from the browser. A user cannot file a request as somebody else, even by editing the payload.

Anonymous — a public privacy page

The public surface is CAPTCHA-gated. The SDK bundles no third-party CAPTCHA script, which keeps your CSP tight, so you render the challenge and hand back a fresh token on demand.
If the server requires a CAPTCHA and no captchaProvider was supplied, submission fails with an explicit error.
Your portal UUID is a public identifier — it appears in your Privacy Center URL and is safe to ship in frontend code. It is not a credential and grants no access on its own.

Authenticated — inside your product

Your API key never reaches the browser. Your backend exchanges it for a short-lived session token, exactly as with the verification flow.
No tenantUuid and no CAPTCHA. The subject’s identity fields arrive prefilled, or are dropped entirely, because the session already supplies them.

What the server decides, not you

The form renders strictly from configuration the server returns, so the same code serves every tenant and jurisdiction:
Never hard-code a field list. It will break the moment a new jurisdiction is enabled for your tenant.
Do not compute the deadline yourself. jurisdiction.deadline_days is absent for jurisdictions with no encoded regulation, and the SDK renders deadline copy only when it is present. Deriving a date in JavaScript gets it wrong — “one month” is not 30 days, and month arithmetic overflows, so 31 January plus one month lands in March. Show what the server sends.

The two outcomes

onSubmit(result) fires once the server accepts the request. There are two shapes, and you must handle both.
  • submitted — accepted. Show message, and the tracking_token if present so the subject can check on it later.
  • biometrics_required — accepted, but it cannot be actioned until the subject proves who they are. Send them to verification_url. The built-in form warns about this before submit, so the step-up is never a surprise.
The bundled terminal screen handles both. Override it with slots.renderTerminal if you would rather do it yourself.

createRightsRequest(options)

RightsRequestController

Errors

A validation error keeps the widget mounted and interactive.

Privacy notes

  • In anonymous mode the subject asserts their own identity. That is exactly why the identity gate and the biometric step-up exist — do not action a request on the strength of the form alone.
  • tracking_token is opaque and contains no personal data. It is safe to show the subject and to store.
  • Responses are enumeration-safe: a request for a subject that does not exist returns the same generic confirmation as one that does. Do not try to infer existence from the response.

Embedding

Much lighter than the verification flow — no camera, no engine, no secure-context requirement. See Embedding requirements.