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
Send a proof request through IDKit, challenging the user to prove something about themselves — such as uniqueness, document possession, or liveness — based on their credentials. The user’s World ID app generates a zero-knowledge proof without revealing personal data. Your backend then verifies the proof and stores a nullifier (a per-app, per-action identifier) to prevent the same person from verifying twice.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}.
Forward the IDKit result payload as-is. No field remapping is required.
app/api/verify-proof/route.ts
Step 6: Store the nullifier
Every World ID 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