Verification API Integration: Real-Time Background and Identity Checks Without Data Storage

February 7, 2026

Verification is one of the most sensitive steps in hiring and onboarding. Identity checks, background screenings, and employment verifications all involve highly personal data and strict regulatory requirements. At the same time, products that rely on verification need timely status updates and consistent behavior across providers.

Verification API integration exists to solve this problem. In this guide, we'll explain what a Verification API actually does, how verification data differs from ATS and HR data, how real-time status updates work in practice, and how Unified's Verification API fits cleanly into hiring and onboarding architectures.

Introduction to Verification API Integrations

Verification providers such as Checkr, Certn, First Advantage, Verifiable, and Yardstik perform point-in-time checks to confirm identity, credentials, or eligibility. Each provider offers different packages, input requirements, turnaround times, and result formats.

Products that need to work with multiple verification providers face familiar challenges:

• Provider-specific APIs and authentication
• Different request parameters and result schemas
• Inconsistent event delivery for status changes
• Strict privacy and data-handling expectations

Verification API integration provides a consistent way to initiate checks, monitor progress, and retrieve results—without building and maintaining separate integrations for each provider.

What Is a Verification API?

A Verification API allows software products to initiate and track identity or background checks programmatically.

In practice, this includes:

• Listing available verification packages
• Creating verification requests for specific individuals
• Monitoring request status changes
• Retrieving verification outcomes and reports

Verification APIs are transactional by design. They perform checks at specific moments in time and return results. They are not systems of record for candidates or employees.

Verification API vs ATS and HR APIs

Unified treats verification, recruiting, and employment as distinct categories, each with clear responsibilities.

• ATS APIs manage recruiting data such as candidates, applications, interviews, and hiring decisions.
• HR & Directory APIs manage employment data such as employees, org structure, benefits, and payroll artifacts.
• Verification APIs perform point-in-time checks and return results.

A verification request may be associated with a candidate in an ATS, but verification data does not create or update candidate, application, or employee records automatically. Any updates to ATS or HR data must be performed explicitly by the application.

Verification data represents a point-in-time check, not an ongoing identity or employment record.

This separation prevents accidental coupling and supports real-world hiring and onboarding scenarios.

Core Verification Data Models (and How They Behave)

Unified's Verification API provides access to two objects only. This narrow scope is intentional.

Packages

Packages describe the checks offered by a provider—such as identity verification, background screening, or employment verification.

Key characteristics:

• Read-only
• Defined by the provider
• Include identifiers, descriptions, pricing information, regional applicability, and typical processing times
• May indicate whether a redirect-based verification step is required or whether an IP address must be supplied

Applications list and retrieve packages to determine which checks are available and what data is required before submitting a request.

Requests

Requests represent individual verification checks initiated for a specific person.

Requests support create, retrieve, list, update, and remove operations, with important lifecycle semantics:

• Creation: A request is created with a selected package and required profile data. Initial status is typically PENDING.
• Processing: Some providers require redirect-based verification for user consent; others process checks directly.
• Completion: When processing finishes, status transitions to values such as PASSED, FAILED, or COMPLETED.
• Expiration: Results may expire after a defined period, requiring a new request for future use.
• Removal: Requests can be removed once no longer needed.

Only a subset of request fields can be modified while the request is pending. Result fields and timestamps are set by the provider and are not editable.

Real-Time Status Updates and Event Delivery

Verification status changes are time-sensitive. Products often need to know as soon as a check completes or fails.

Native and Virtual Webhooks

Unified uses a hybrid event-delivery model:

• Native webhooks are forwarded immediately when supported by the provider.
• Virtual webhooks poll the provider at a configurable interval and deliver updates when changes are detected.

Both delivery methods use the same subscription interface and payload format.

Supported Events

Across providers:

• request.created
• request.updated (used to signal status changes and result availability)

There is no separate status event. When a verification completes or transitions state, an updated event is sent.

Provider Variability

Webhook support varies by provider:

• Some providers support native webhooks for verification requests.
• Others rely entirely on virtual webhooks generated through polling.
• Package-level events are limited and not universally available.

Applications should design event handling with provider variability in mind and avoid assuming universal webhook coverage.

Security, Privacy, and Data Handling

Verification data is highly sensitive. Unified's architecture is designed to minimize risk.

Zero-Storage Architecture

• Verification data is routed directly to the source provider in real time.
• No verification payloads are stored at rest.
• No replicas or data warehouses are created.
• Requests are stateless.

If long-term storage is required, applications must persist results in their own systems (for example, within ATS or HR platforms).

Result and Document Handling

• Verification results are returned in standardized fields such as status, score, and details.
• Some providers return download URLs for reports; these URLs are time-limited.
• Unified does not retain or cache verification reports or documents.

PII Handling and Masking

• Normalized fields return only the data required to complete or interpret a verification.
• Additional provider-specific fields are returned only when explicitly requested.
• In MCP-based integrations, a hide_sensitive option can remove personally identifiable information from responses before data reaches downstream systems such as LLMs.

Controls and Compliance

Unified supports industry-standard security controls:

• SOC 2 Type II
• GDPR, CCPA/CPRA, HIPAA, and PIPEDA alignment
• TLS 1.2+ for data in transit
• AES-256 encryption for minimal diagnostic fields
• SAML/OIDC SSO, role-based access, and IP allow-listing
• Optional external log forwarding for customer-owned observability

Verification and ATS Integration Patterns

Verification commonly sits between recruiting and employment.

Typical patterns include:

• Creating a verification request after a candidate accepts an offer
• Monitoring verification status via webhooks or polling
• Updating application status or notes in the ATS based on results
• Proceeding to HR onboarding only after verification completes

These steps are coordinated through explicit API calls. The Verification API does not update ATS or HR records automatically.

Challenges and Constraints to Plan For

Unified is explicit about Verification limitations:

• Only packages and requests are available
• Verification results are point-in-time and may expire
• Provider requirements differ by region and package
• Webhook coverage varies by provider
• Applications must handle persistence and downstream updates

These constraints reflect real provider behavior and help avoid hidden assumptions.

Build vs Buy Verification Integrations

Building In-House

• Separate integrations for each provider
• Provider-specific parameters and result formats
• Custom polling and event handling
• Ongoing maintenance as providers change APIs

Using a Unified Verification API

• One category-specific API surface
• Standardized packages and request handling
• Consistent event delivery model
• Centralized authentication and maintenance
• Usage-based pricing aligned with API volume

Best Practices for Implementing Verification APIs

• Treat verification as transactional, not persistent
• Initiate requests only when required by your process
• Design for provider-specific input requirements
• Handle expiration of results explicitly
• Keep ATS and HR updates under application control
• Review regional and regulatory constraints per package

Build Verification integrations the right way

If your product depends on background or identity checks, maintaining separate verification integrations introduces unnecessary risk and overhead.

Unified's Verification API provides a consistent way to initiate checks, monitor status, and retrieve results across multiple providers—without storing verification data or coupling verification logic to recruiting or HR records.

→ Start your 30-day free trial

Test verification integrations with real-time status updates and direct API access.

→ Book a demo

Talk through your verification, ATS, or onboarding use case with the team that built the platform.

FAQ

What is a Verification API?

An API that allows products to initiate and track identity or background checks programmatically.

Which providers are supported?

Unified supports providers such as Certn, Checkr, First Advantage, Verifiable, and Yardstik.

Does the Verification API store personal data?

No. Verification data is not stored at rest. Applications must persist any required results themselves.

Are verification updates real time?

Status changes are delivered via native or virtual webhooks where supported, otherwise through polling.

Does a verification request create an employee or candidate record?

No. Verification requests do not create or update ATS or HR records automatically.

How long are verification results valid?

Validity depends on the provider and package. Many results include an explicit expiration timestamp.