@worldcoin/idkit-standalone to @worldcoin/idkit-core. The idkit-standalone package has been discontinued. If you used it
for a vanilla JavaScript or custom QR flow, migrate 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
In standalone, the package 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 App returns a proof.
After
Credential Mapping
Standalone usedverification_level to choose what the user should prove. In
idkit-core, use a legacy preset instead. These presets are drop-in
replacements for the old verification levels.
The legacy presets will return the maximum credential a user has. For example, if a user has an Orb credential, but you request
documentLegacy, they will verify with their Orb credential.| Standalone | idkit-core preset |
|---|---|
verification_level: "orb" | orbLegacy({ signal }) |
verification_level: "secure_document" | secureDocumentLegacy({ signal }) |
verification_level: "document" | documentLegacy({ signal }) |
verification_level: "device" | deviceLegacy({ signal }) |
RP Signatures
IDKit 4.x requests requirerp_context, signed by your backend with the
Developer Portal signing_key. Do not generate signatures in client code.
For implementation details, use the RP Signatures
reference. It includes the JavaScript helper, the signing algorithm, and test
vectors for non-JavaScript backends.
Verify the Proof
Standalone integrations usually 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.