Choose an entry point
Most integrations use exactly one of these.Identity verification
idesify/verification — mounts the full capture flow (document, selfie, review) and reports the server’s decision.Rights requests
idesify/rights — a server-driven DSAR / ARCO form for access, deletion, portability, and the rest.Consent management
idesify/consent — server-driven purposes and legal clauses, recording the subject’s decision.Low-level capture
idesify — camera orchestration and the frame bridge, for building your own capture UI.How the entry points differ
rights and consent are standalone and framework-free. They pull in no camera and no engine, so a widget-only integration installs nothing beyond the idesify package.Two rules that shape every integration
These apply to all entry points, and getting them wrong is the most common source of integration bugs.1
Your API key never reaches the browser
Your backend exchanges the API key for a short-lived session token, and the SDK runs on that token. Mint the token just before mounting, and re-mint it when the SDK reports it expired.
2
The server decides — always
On-device detection only frames the shot. It guides the user’s camera and nothing more. Every decision that matters is made server-side and delivered to your completion callback.Treat that callback as the only source of truth. Never branch your business logic on anything you observe during capture.
Server-driven by design
All three widgets render strictly from configuration the server returns:- Verification — which screens appear, which documents are offered, and whether each is captured front-only or front-and-back.
- Rights — which request types are offered, and which form fields apply in the subject’s jurisdiction.
- Consent — which purposes and legal clauses are presented, already localized.
Install and check compatibility
Package setup, the optional peer dependency, and supported browsers and runtimes.