Skip to main content
This guide helps you migrate from @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

  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

In standalone, the package 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 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.

RP Signatures

IDKit 4.x requests require rp_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 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.