@reclaimprotocol/client 0.1.41 → 0.1.43

package/README.md

@@ -341,7 +341,8 @@ const verifierApp = await reclaim.sessions.create({
   verificationClientUrl: VerificationClient.verifierApp,
 })
 
-// 4. In-app SDK or add-to-app host.
+// 4. In-app SDK or add-to-app host. Required for these apps: pass
+//    inApp.verificationUrl to the app's startVerificationFromUrl.
 const inApp = await reclaim.sessions.create({
   providers: [{ providerId }],
   context,
@@ -372,6 +373,22 @@ const custom = await reclaim.sessions.create({
 })
 ```
 
+A session works only in the client it was created for. Builder fixes the
+session's client at creation, and every Verification Client request must carry
+that client's `x-reclaim-vc-id`, or it gets
+`403 x-reclaim-vc-id does not match this session`. Opening the link in another
+client first doesn't change this. So a mobile app using the in-app SDK or the
+add-to-app module needs sessions created with `VerificationClient.inAppSdk`
+(`https://build.reclaimprotocol.org/share/inapp-sdk`). A session created
+without `verificationClientUrl` is a Portal session, and those apps can't open
+it.
+
+Those apps start Builder mode from either value of the response:
+- `startVerificationFromUrl(inApp.verificationUrl)`;
+- `startVerificationFromJson({ api: '2', sessionId: inApp.id })`.
+  Add `diag: '1'` only when `verificationUrl` contains `diag=1`. Other keys
+  are ignored, and the Builder URL comes from the app's configuration.
+
 The Consumer supplies a URL, not `verificationClientId` or
 `x-reclaim-vc-id`. Builder resolves and stores the UUID. The selected
 Verification Client reads its own configured UUID and sends it only on its
@@ -565,6 +582,10 @@ curl -X POST "$BUILDER_URL/verifications/sessions" \
 # → 201 { "id": "…", "verificationUrl": "…&api=2", "status": "pending", "mode": "…", … }
 ```
 
+For the in-app SDK or add-to-app module, send
+`"verificationClientUrl": "https://build.reclaimprotocol.org/share/inapp-sdk"`.
+Those apps can't open a session created for another client.
+
 For a TEE-bound session, a raw HTTP client must derive the legacy hash nonce
 with its organization verification private key, sign the exact
 `RECLAIM_BUILDER_TEE_BINDING_V1:{organizationId}:{sessionId}:{applicationId}:{timestamp}:{attestationVersion}:{attestationNonce}`
@@ -668,7 +689,8 @@ reclaim.sessions.create({ providers, context, verificationClientUrl?, orgEthPriv
   // providers: { providerId, version? }[] — proved in order, one combined result; all required.
   // → VerificationSession (has `id`, `verificationUrl`, `status`, `mode`, …)
   // verificationClientUrl selects a registered Verification Client by URL;
-  // omitted, it defaults to the Portal.
+  // omitted, it defaults to the Portal. The session then only opens in that
+  // client: use VerificationClient.inAppSdk for in-app SDK / add-to-app hosts.
   // orgEthPrivateKey optionally creates the post-create TEE binding locally.
   // The returned verificationUrl contains sessionId and api=2.
 reclaim.sessions.bindTeeNonce(reclaimSessionId, { orgEthPrivateKey, timestamp? })

package/package.json

@@ -1,7 +1,7 @@
 {
 	"name": "@reclaimprotocol/client",
 	"title": "Reclaim Client",
-	"version": "0.1.41",
+	"version": "0.1.43",
 	"description": "Typed SDK/HTTP client SDK for the Reclaim Protocol — the programmatic way to use Reclaim Protocol to verify **data points** about your users (a follower count, an account balance, an order). Can be directly integrated by apps to request verification for their users using Reclaim Protocol and verify the results.",
 	"type": "module",
 	"sideEffects": false,