@worldcoin/idkit-standalone package is discontinued. Migrate any vanilla JavaScript or custom QR flow to @worldcoin/idkit-core.
Migration Checklist
- Enable World ID 4.0 in the Developer Portal and keep your
app_id,rp_id, and server-onlysigning_key. - Install
@worldcoin/idkit-core. - Add a backend endpoint that generates an RP signature. See RP Signatures.
- Pick a legacy preset that matches your previous
verification_levelconfiguration. - Replace
verifyCloudProof(...)with a backend POST tohttps://developer.world.org/api/v4/verify/{rp_id}. - Store the verified
nullifierfor replay protection.
Install
Request a Proof
Standalone mounted UI through browser globals:Before
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 usedverification_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 requirerp_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 withverifyCloudProof(...):
Before
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.