Skip to main content
The @worldcoin/idkit-standalone package is discontinued. Migrate any vanilla JavaScript or custom QR flow to @worldcoin/idkit-core.

Migration Checklist

  1. Enable World ID 4.0 in the Developer Portal and keep your app_id, rp_id, and server-only signing_key.
  2. Install @worldcoin/idkit-core.
  3. Add a backend endpoint that generates an RP signature. See RP Signatures.
  4. Pick a legacy preset that matches your previous verification_level configuration.
  5. Replace verifyCloudProof(...) with a backend POST to https://developer.world.org/api/v4/verify/{rp_id}.
  6. Store the verified nullifier for replay protection.
For the broader protocol migration, including proof types and timelines, see World ID 4.0.

Install

Request a Proof

Standalone mounted UI through browser globals:
Before
With idkit-core, fetch an RP signature from your backend, build the request, render the connectorURI, and poll until World ID returns a proof.
After

Credential Mapping

Standalone used verification_level to choose what the user proves. In idkit-core, use a legacy preset instead. These presets only return World ID 3.0 proofs — a compatibility step, not the final migration target.
Legacy presets return the maximum credential a user has. For example, if a user has an Orb credential but you request documentLegacy, they verify with their Orb credential.
For World ID 4.0, use the v4-native presets: proofOfHuman (replaces orbLegacy), passport (NFC passports/eIDs), or mnc (Japanese My Number Card). They always keep World ID 3.0 fallback on, regardless of allow_legacy_proofs. A single preset narrows a document integration, since documentLegacy accepted Orb, passport/eID, and MNC holders alike; to keep all of them, use .constraints(any(CredentialRequest("proof_of_human"), CredentialRequest("passport"), CredentialRequest("mnc"))). Constraint requests have no credential-specific 3.0 fallback (any 3.0 fallback is Device-level), so use them with allow_legacy_proofs: false, which is also how you drop World ID 3.0 entirely. See Configure Credentials.

RP Signatures

IDKit 4.x requests require rp_context, signed by your backend with the Developer Portal signing_key. Never generate signatures in client code. For implementation details, see the RP Signatures reference. It includes the JavaScript helper, the signing algorithm, and test vectors for non-JavaScript backends.

Verify the Proof

Standalone integrations typically verified with verifyCloudProof(...):
Before
In IDKit 4.x, send the IDKit result to your backend and forward it directly to the v4 verify endpoint.
After

Store the Nullifier

After /api/v4/verify/{rp_id} succeeds, store the verified nullifier for the action and reject duplicates. During migration, keep checking any old nullifier_hash records if the same user could have verified before the upgrade.