> ## Documentation Index
> Fetch the complete documentation index at: https://docs.idesify.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Drop-in identity verification, rights requests, and consent management for the browser

The Idesify browser SDK ships three products as embeddable widgets, plus a low-level entry for teams that want to build their own capture UI. You install one package and import only the part you need.

```bash theme={null}
npm install idesify
```

## Choose an entry point

Most integrations use exactly one of these.

<Columns cols={2}>
  <Card title="Identity verification" icon="id-card" href="/sdk/verification/quickstart">
    `idesify/verification` — mounts the full capture flow (document, selfie, review) and reports the server's decision.
  </Card>

  <Card title="Rights requests" icon="file-shield" href="/sdk/privacy/rights">
    `idesify/rights` — a server-driven DSAR / ARCO form for access, deletion, portability, and the rest.
  </Card>

  <Card title="Consent management" icon="check-double" href="/sdk/privacy/consent">
    `idesify/consent` — server-driven purposes and legal clauses, recording the subject's decision.
  </Card>

  <Card title="Low-level capture" icon="camera" href="/sdk/install#the-low-level-entry">
    `idesify` — camera orchestration and the frame bridge, for building your own capture UI.
  </Card>
</Columns>

## How the entry points differ

| Import | Camera | On-device engine | Typical host page |
| - | - | - | - |
| `idesify/verification` | Required | Required | Your onboarding flow |
| `idesify/rights` | No | No | Your public privacy page, or your logged-in product |
| `idesify/consent` | No | No | Your public privacy page |
| `idesify` | Required | Required | A custom capture UI you build yourself |

<Note>
  `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.
</Note>

## Two rules that shape every integration

These apply to all entry points, and getting them wrong is the most common source of integration bugs.

<Steps>
  <Step title="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.

    ```text theme={null}
    Your frontend ──▶ Your backend ──(API key)──▶ Idesify
                           │
                           ▼
                     session token  ──▶  the SDK
    ```
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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.

Change any of it in your dashboard, not in your code. No redeploy is required, and hard-coding a field list or a document list will break the moment a new jurisdiction is enabled.

<Card title="Install and check compatibility" icon="arrow-right" horizontal href="/sdk/install">
  Package setup, the optional peer dependency, and supported browsers and runtimes.
</Card>