Skip to main content
All endpoints require an API key as a Bearer Authorization header. API keys must only be used in backend server code.

Integration Steps

1

Create a Verification Session

Your backend calls the Predicate API to create a KYC or KYB session
2

Display the QR Code and Link

Show the QR code or redirect URL to the user in your application
3

Monitor Session Status

Use SSE (recommended) or polling to track verification progress
4

Verify Wallet Addresses

Check if a wallet belongs to a verified identity before transactions

Step 1: Create a Verification Session

Your backend creates a session by calling the registration endpoint. The response includes a QR code and redirect URL for the user.
cURL
Request Body (Optional):
Wallet Constraint: When you include walletAddress in the request:
  • The user can only connect and verify with that specific wallet address
  • If a session (pending, retry, or completed) already exists for that wallet with the same verification type, the existing session is returned (session reuse)
  • Sessions are only reused within the same check type (KYC sessions for /register/individual, KYB for /register/business)
  • Useful for pre-registering known wallet addresses or enforcing wallet constraints
Origin URL: Pass an optional originUrl (an absolute https:// URL) to give the user a button back to your application when they finish the verification flow (and while a manual review is pending, with a note that they are not yet authorized). It is named originUrl so it is not confused with the response redirectUrl, which is the hosted verification link you send the user to.
HTTP Status Codes:
  • 201 Created - A new session was created
  • 200 OK - An existing session was reused (when walletAddress matched an existing reusable session)
Response:
Display the base64-encoded QR code from the response directly in an <img> tag.
What happens on the verification portal:
  • User lands on the verification page
  • User connects their wallet(s) - up to 20 per session, across different chains
  • User completes identity verification
  • Session status updates are sent via SSE
  • When finished (or while a manual review is pending), the user can return to your application using the originUrl you provided (if any)

Step 3: Monitor Session Status

Once a user starts verification, monitor their progress using SSE (recommended) or polling. Session Status Values:
Important: A submitted status means documents are under manual review. The wallet is not verified until status becomes completed.

Verifying Wallet Addresses

Once a user has completed verification, check if any wallet address belongs to a verified identity.
cURL
Response (verified):
Response (not verified):
Verification Levels: The verify endpoint returns verified status for wallets that were verified at your organization’s current verification level. If you upgrade your verification level, previously verified wallets will need to re-verify. Wallets verified through other organizations at the same scrutiny level will also appear as verified.

Best Practices

Security

  • Never expose API keys in frontend code - All authenticated operations must happen on your backend
  • Use environment variables - Store API keys in .env files or secure secret management systems
  • Validate session IDs - Always validate UUID format before making API calls
  • Verify session ownership - The API ensures sessions can only be accessed by the customer that created them

User Experience

  • Show clear progress indicators - Update the UI as session status changes
  • Handle all statuses - Display appropriate messages for pending, submitted, completed, rejected, and retry
  • Explain submitted status to users - When status is submitted, inform users that their documents are under review and they’ll be notified when a decision is made. submitted does NOT mean approved.
  • Provide both QR and link - Some users prefer clicking, others prefer scanning
  • Consider timeouts - Sessions don’t expire, but you may want to implement client-side timeouts

Performance

  • Use SSE over polling - Real-time updates are more efficient and user-friendly
  • Implement reconnection logic - Handle network interruptions gracefully
  • Close connections when done - Stop monitoring once verification completes or fails

Complete Integration Example

Here’s a full example tying everything together:

API Reference

Query Parameters for Registration Endpoints:
  • size (optional): QR code size in pixels, between 80 and 2000. Default: 300.
All API endpoints require a Bearer token: