igrantio-individualslisted

# iGrant.io individuals (Consent BB admin Individual API) ## When to use When your app onboards a user, create a matching **individual** in the iGrant.io Consent Building Block and store the returned `individualId` against your own `userId`. That mapping is what later lets `igrantio-consent-records` record and manage consents for the right person. ## Integrator intake Ask one question at a time, a recommended default with each; look up facts in the project, put only decisions to the integrator: 1. **Environment** - demo (`https://demo-api.igrant.io`), staging, or a custom Consent BB deployment (ask its base URL)? _Recommend demo to start._ 2. **API key** - organisation API key for the Consent Building Block? From your iGrant.io organisation account; server-side only, never the browser. 3. **Mapping storage** - where does the `userId` to `individualId` mapping live: a column on the existing users table (recommended) or a separate store? ## The mapping (the important part) ``` your users table Consent BB +----------+-------------+ +---------------------------+ | user_id | individual | <──────► | individual { id, ... } | | u_123 | 6541...cd | | externalId = "u_123" | +----------+-------------+ +---------------------------+ ``` Persist `individualId` in YOUR database keyed by your `userId`. The reference uses `externalId = your userId` so the individual is also recoverable from OWS if the local mapping is ever lost