Tip: To integrate faster, give your coding agent the Build with LLMs prompt — copy it once, then paste into Claude, Cursor or any AI coding assistant.
How it works
Use IDKit to request a proof and verify it on your backend: follow this guide for one-time checks, or use session proofs for returning users.Step 1: Install IDKit
Use the latest4.x version.
Step 2: Create an app in the Developer Portal
Create your app in the Developer Portal. If you’re migrating from an old app, complete RP registration by clicking the Enable World ID 4.0 banner. Keep these values:app_idrp_idsigning_key- this should be stored as a secret.
Step 3: Generate an RP signature in your backend
Signatures verify that proof requests come from your app, preventing impersonation attacks.The steps below cover the standard request flow. Depending on whether the user
already has World ID and the credential you’re requesting, they may see a
different experience. See Verification flows
for details.
Step 4: Generate the connect URL and collect proof
To test during development, use the simulator and setenvironment to "staging".
IDKit response
After the user completes the verification flow, IDKit returns one of the following response shapes, depending on the protocol version and proof type.Step 5: Verify the proof in your backend
After completion, send the returned payload to your backend and forward it directly toPOST https://developer.world.org/api/v4/verify/{rp_id}. Check that the verify response’s environment matches your backend’s expected environment (assert "production" for production integrations).
Forward the IDKit result payload as-is. No field remapping is required.
app/api/verify-proof/route.ts
Step 6: Store the nullifier
This step applies to uniqueness requests. For session proofs, follow the session guide. Every uniqueness proof contains a nullifier — a value derived from the user’s World ID, your app, and the action. The same person verifying the same action always produces the same nullifier, but different apps or actions produce different ones, making nullifiers unlinkable across apps. The Developer Portal confirms the proof is cryptographically valid, but your backend must check that the nullifier hasn’t been used before. Otherwise, the same person could verify multiple times for the same action. Nullifiers are returned as 0x-prefixed hex strings representing 256-bit integers. Convert and store them as numbers to avoid parsing and casing issues that can lead to security vulnerabilities. For example, PostgreSQL doesn’t natively support 256-bit integers, so convert the nullifier to a decimal and store it asNUMERIC(78, 0).
Architecture detail
Next pages
- RP Signatures — algorithm details, pseudocode, and test vectors
- POST /v4/verify reference