Account Binding
Account Binding is the most direct way to link CLEAR verifications to existing user records.
How it works:
- When creating a verification session, you include your own identifier (e.g.,
customer_id,employee_id) in a custom field. - CLEAR stores that identifier alongside the verification session.
- When you call Get Verification Session, CLEAR returns the identifier exactly as provided.
- Your system uses the identifier to bind the verification to the correct user profile.
Example Flow
- Partner app generates a verification session and includes a custom identifier:
{ "custom_fields": { "newKey": "New Value", "customer_id": "12345" } }
- User completes CLEAR verification.
- Partner retrieves the session and sees:
{
"verification_session_id": "verify_abc123",
"status": "success",
"custom_fields": {
"customer_id": "12345"
},
"user_id": "psuid_xyz987"
}
- Partner looks up customer_id = 12345 in their system and binds that profile to the CLEAR user_id.
Best Practices
First-time binding:
When binding a CLEAR user to an existing profile for the first time, we recommend also performing biographic matching. This ensures the attributes provided (name, DOB, etc.) align with the existing record, reducing the chance of a mistaken link.
After binding:
Once a CLEAR user has been bound to your record, use the CLEAR PSUID / user_id for all subsequent matches. This gives you a persistent, global identifier you can rely on across sessions.
Avoid overwrites:
Do not overwrite an existing binding without explicit checks. A PSUID should only ever map to one record in your system.
When to Use Account Binding
Use Account Binding if:
- You already have strong identifiers in your system (employee ID, customer ID, etc.).
- You want deterministic, one-to-one binding between CLEAR and your users.
- You’re comfortable managing the binding lifecycle in your own database.
- If your system does not have reliable identifiers, consider Data Matching or Biographic Matching API.
Updated 2 days ago