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

Verification API integration lets your product order identity, background and employment checks from providers such as Checkr, Certn and Socure, then track each check's status and read its result, through one API instead of one integration per provider. Unified.to's Verification API does this with two objects, packages and requests, across 24 providers, on every plan. This guide is for developers building hiring, onboarding, marketplace or compliance products.

Verification is one of the most sensitive steps in hiring and onboarding: checks involve personal data and strict regulatory requirements, and every provider has its own API. Below: what a verification API does, how it differs from ATS and HR APIs, how status events work, and how Unified.to handles the data.

Why integrate more than one verification provider?

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 gives you one way to start checks, monitor progress and retrieve results, without a separate integration 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.

How is a verification API different from ATS and HR APIs?

Unified.to treats verification, recruiting and employment as separate categories.

• 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 through its candidate_id, 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.

What objects does the Verification API use?

Unified.to's Verification API has two objects: a package is a check a provider offers, and a request is one ordered check with its result.

For per-integration support, see the Verification API overview and supported integrations. For a provider-by-provider view, see 5 Verification APIs to Integrate With in 2026.

Packages

Packages describe the checks a provider offers. Each has a type: identity verification, screening, background check, employment verification, education verification, credit check, fraud prevention or other.

Key characteristics:

• Read-only
• Defined by the provider
• Can include a description, cost, valid regions and average processing time, where the provider supplies them (as of 19 October 2026, cost on Accurate and Checkr; regions on IDfy, Socure and Trulioo; processing time on Verifiable)
• Can indicate whether the check sends the candidate to the provider's own page (has_redirect_url, on Checkr and Verified First)

Applications list packages (and retrieve one, where supported) to see which checks are available and what data each needs before submitting a request.

Requests

Requests represent individual verification checks initiated for a specific person.

Requests support create on nearly every integration and retrieve on most; list, update and remove depend on the integration (update on Certn, Checkr and Yardstik; remove on Checkr, TrustID, Verifiable, Yardstik and Zinc, as of 19 October 2026). An unsupported operation returns 501. A request moves through these stages:

• Creation: A request is created with a selected package and required profile data. Its response_status is PENDING until the provider reports an outcome.
• 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: on some integrations (Checkr, Makesure, Verifiable and Yardstik, as of 19 October 2026) the result carries an expiry date in response_expires_at; order a new check after it.
• Removal: where the integration supports it, a request can be removed.

Where update is supported, only input fields (package and profile details) are writable. Result fields and timestamps come from the provider and are read-only on every integration.

How do you find out when a check finishes?

Subscribe to webhooks on the verification request object, on integrations that send them; otherwise retrieve the request by ID. A check finishes when the provider finishes it, which depends on the provider and package.

Native and Virtual Webhooks

Unified.to delivers two kinds of webhook:

• Native webhooks pass on the provider's own events.
• Virtual webhooks check the provider at an interval you set, as often as every minute on paid plans, and send an event when something changed; a check that finds nothing isn't billed.

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

Which events are available?

On the verification_request object: created and updated (status changes and results arrive as updated), plus deleted on Yardstik. On verification_package: Checkr only (as of 20 October 2026).

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

Which integrations send events?

As of 20 October 2026:

• Native request events: Accurate, Checkr, SambaSafety, Sterling, Sterling Check, Tazworks, TrustID, Verified First, Yardstik and Zinc.
• Virtual request events: Verifiable, TrustID, Yardstik and Zinc.
• No events: Certn, First Advantage, Harver, IDfy, IDmission, Makesure, Socure, Trulioo and Verified Credentials; read the request instead.

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

What does Unified.to store from verification data?

Unified.to keeps no customer records at rest; connection credentials and operational metadata are encrypted at rest.

How requests are handled

• Each request goes to the provider when you make the call.
• No customer records, verification payloads or reports are kept 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 integrations return report download URLs in response_download_urls (for example Accurate, SambaSafety and Verified First); the provider controls how long they work.
• Unified.to does not keep or cache verification reports or documents.

PII Handling and Masking

• Standard fields carry only what's needed to order or interpret a check.
• Provider fields outside the model come back in the raw field when you request them with fields.
• 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.to's security controls:

• SOC 2 Type II report
• GDPR, CCPA/CPRA, PIPEDA and HIPAA compliance; HIPAA BAA on Scale
• TLS 1.2+ in transit
• AES-256 encryption at rest for operational metadata
• Admin and member roles; SAML SSO and IP restriction on Pro and Scale
• Log shipping to your own tools on Pro and Scale

How does verification fit into a hiring process?

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.

What limits should you plan for?

Plan for these:

• 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 integration (nine send no events, as of 20 October 2026)
• Applications must handle persistence and downstream updates

Should you build verification integrations or use a unified API?

Build in-house if you only ever need one provider; use a unified API when customers bring different providers.

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
• One webhook model on integrations that send events
• Centralized authentication and maintenance
• Usage-based pricing aligned with API volume

What are the best practices for verification API integration?

• 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

Get started

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

Unified.to's Verification API gives you one way to start checks, monitor status and retrieve results across providers, with no customer records at rest and no coupling to recruiting or HR records.

→ Start your 30-day free trial

Test verification integrations with status events 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.to supports 24 verification providers, including Checkr, Certn, First Advantage, Socure, Sterling Check, Trulioo, Verifiable and Yardstik. See supported integrations.

Does the Verification API store personal data?

No customer records are kept at rest; connection credentials and operational metadata are encrypted at rest. Store any results you need in your own systems.

How do I know when a check is complete?

Through native or virtual webhooks on integrations that send them; otherwise retrieve the request by ID.

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. Some integrations return an expiry date in response_expires_at.