After a verification session completes, CLEAR returns user identifiers and (optionally) biographic data to your backend. How you store this information depends on your compliance requirements, security policies, and integration approach.

The goal is to ensure you can:

• Recognize returning users without re-verifying unnecessarily
• Audit verification events for compliance and support
• Protect sensitive data with appropriate safeguards

What CLEAR Returns

When you call Get Verification Session, CLEAR provides:

• User ID (user_id) — a persistent identifier for the verified user (recommended to always store)
• Verification ID — identifier for the specific verification session (useful for audits, support, and re-fetching results)
• Traits — verified user attributes (e.g., name, DOB, phone, email) if your project is configured to return them
• PII — sensitive fields (e.g., SSN, ID images) only if explicitly enabled and your system is authorized to receive them

Storage Recommendations

• Always store:

  • UserID (user_id) → allows you to match returning users deterministically
  • Verification ID → provides traceability back to the exact session

• Store PII cautiously:

  • Only store what is required for your workflow or regulatory environment
  • Use a secure, encrypted data store and apply strict access controls
  • If possible, design your system to use User ID instead of raw PII

• Audit and logging:

  • Log verification outcomes (e.g., success, failure, expired)
  • Retain Verification IDs for compliance and troubleshooting

Working with Verification Results

When a verification session is complete, you must explicitly pull the results from the Get Verification Session API. This ensures you know the outcome, the checks that were run, and any user data (PII) returned by CLEAR.

1. Get Verification Session

curl https://secure.verified.clearme.com/v1/verification_sessions/{verification_session_id} \
  -H 'Authorization: Bearer <API_KEY>'

2. Check Verification Stations

The status field tells you the overall outcome:

success → user verified

failed → verification failed

expired → session timed out

awaiting_user_input → user abandoned or not finished

canceled → verification was canceled

3. Review Individual Checks

The checks array contains the detailed results of each verification step. Each entry includes a name, value, and status.

Example:

"checks": [
  {
    "name": "Gov ID is not expired",
    "value": true,
    "status": "completed"
  },
  {
    "name": "Selfie matches portrait on Gov ID",
    "value": true,
    "status": "completed"
  }
]

value: true → check passed

value: false → check failed

Use this for auditing, troubleshooting, or custom decisioning.

4. Accessing PII (traits.document)

Verified personal information is returned under the traits.document object. Fields may include:

document_type (e.g., drivers_license, passport)

issuing_country, issuing_subdivision

document_number

date_of_expiry

date_of_birth

first_name, last_name, middle_name

address (line1, city, state, postal_code, country)

gender

"traits": {
  "document": {
    "document_type": "drivers_license",
    "issuing_country": "USA",
    "issuing_subdivision": "NJ",
    "document_number": "1537331",
    "date_of_expiry": {
      "day": 24,
      "month": 12,
      "year": 2031
    },
    "first_name": "JOHN",
    "last_name": "DOE",
    "date_of_birth": {
      "day": 1,
      "month": 1,
      "year": 1990
    },
    "address": {
      "line1": "123 Test St",
      "line2": "Apt A",
      "city": "Test City",
      "state": "NJ",
      "postal_code": "12345",
      "country": "US"
    }
  }
}

4. Accessing Images (traits.document)

By default, sensitive fields in the verification session response are redacted. This includes fields such as:

• ssn
• document_front
• document_back

Default Behavior

When you call the standard endpoint without any parameters, these fields are returned as REDACTED.

GET \
  --url 'https://verified.clearme.com/v1/verification_sessions/{verification_id}' \
  --header 'accept: application/json' \
  --header 'authorization: Bearer {API key}'

Response:

{
  "ssn": "REDACTED",
  "document_front": "REDACTED",
  "document_back": "REDACTED"
}

Reveal Sensitive Data

To retrieve sensitive fields such as SSN or document images, add the reveal_sensitive_data query parameter.

Example:

GET \
  --url 'https://verified.clearme.com/v1/verification_sessions/{verification_id}?reveal_sensitive_data=true' \
  --header 'accept: application/json' \
  --header 'authorization: Bearer {API key}'

Response:

{
  "ssn": "123456789",
  "document_front": "<base64 image string>",
  "document_back": "<base64 image string>"
}

You can also explicitly set the parameter to false to ensure sensitive fields are redacted:

GET \
  --url 'https://verified.clearme.com/v1/verification_sessions/{verification_id}?reveal_sensitive_data=false' \
  --header 'accept: application/json' \
  --header 'authorization: Bearer {API key}'

Best Practices

• Prefer identifiers over PII:
  Rely on CLEAR's User ID for long-term user matching. This avoids repeated exposure of sensitive data.

• Use the secure endpoint:
  Fetch verification data from https://secure.verified.clearme.com/... when handling sensitive traits.

• Implement data retention policies:
  Align storage duration with your compliance and business needs. Delete PII once it is no longer required.

• Design for audits:
  Keep a record of verification events (Verification ID, timestamp, outcome) to support compliance checks or user support requests.

• Always check status before trusting verification results.

• Use checks for fine-grained visibility (e.g., log which validations passed/failed).

• Persist CLEAR's User ID (user_id) and verification_id for future lookups.

• Handle PII: store any PII that your workflow requires, and protect it with appropriate security controls, or store a verificationID to ping CLEARs api for a user's sessiondata indefinitely

Key Takeaway

Data Storage is about storing the data you need to run your workflows reliably.

• Use CLEAR's User ID for persistent matching.
• Store Verification IDs for traceability.
• Handle PII with care, only if required.
• To finalize a verification:
  • Fetch the session using the API.
  • Check status for the outcome.
  • Inspect checks for detailed pass/fail results.
  • Pull traits.document for verified PII if required.
• Default to redacted mode unless your workflow requires sensitive data.
  • Use reveal_sensitive_data=true only when necessary, and apply strict storage and access controls.
  • Treat sensitive data as high-risk and follow your compliance/security requirements for handling PII.