Best Unified API for Employment and Identity Verification in 2026

Unified.to is the unified API for products that order identity, background or employment verification checks from several providers and also need the ATS or HR records around them. Its Verification API covers 24 providers, including Checkr, Certn, Sterling Check, First Advantage, Socure and Trulioo, through two objects: package (a check a provider offers) and request (an ordered check and its result). Finch fits if you only need employment and payroll records; Kombo fits if you sell checks and want ATSs to send you orders (both as of 8 October 2026).

For objects and per-integration support, see the Verification API overview. For the providers' own APIs, see 5 Verification APIs to Integrate With in 2026.

What is an employment verification API, and which unified APIs offer one?

An employment verification API lets your application order a check that confirms a candidate's past employment through a screening provider, then read the result back; among unified APIs, Unified.to offers this through its Verification API, where EMPLOYMENT_VERIFICATION is one of eight package types. The others are BACKGROUND_CHECK, IDENTITY_VERIFICATION, EDUCATION_VERIFICATION, CREDIT_CHECK, SCREENING, FRAUD_PREVENTION and OTHER.

In Unified.to, an employment verification takes three steps:

1. List packages on the connection and pick one whose type is EMPLOYMENT_VERIFICATION. Each package lists the parameters (questions) the check needs and its valid_regions, plus average_processing_times and cost_amount where the provider publishes them.
2. Create a request with the package_id, the candidate's profile (profile_name, profile_date_of_birth, profile_addresses, profile_emails) and, optionally, a candidate_id that points to an ATS candidate.
3. Read the outcome from response_status (PENDING, PASSED, FAILED or COMPLETED), response_details and response_download_urls (the report). Where the provider needs the candidate to confirm previous employers, the request carries a response_redirect_url.

Which providers sell an employment verification package depends on each provider's catalogue, and Unified.to's API reference (1 October 2026) doesn't record it per provider. List a connection's packages before you commit to a provider.

Among other unified APIs, as of 8 October 2026:

• Finch reads employment and payroll records, including employment status and income history, from HRIS and payroll systems. Its products (Organization, Payroll, Deductions, Benefits, Recordkeeper, Documents) don't include ordering verification checks.
• Kombo sells an "Assessment & Background Check" API that works in the other direction: the systems it lists are ATSs (for example PageUp and JazzHR), and an ATS order reaches the check vendor as an assessment:order-received event.
• Merge and Apideck have no verification category: Merge lists eight categories and Apideck 24 APIs, none of them verification.

What does a complete verification workflow need?

A complete verification workflow needs six things: access to the candidate or employee record (ATS or HRIS), a way to order a check, handling for checks that stay PENDING until the provider finishes, status change events, result retrieval (status, score, report), and a way to write the outcome back to hiring or onboarding. A typical hiring flow pulls a candidate from the ATS, orders a background check, tracks its status, then moves the candidate forward in the ATS or onboarding system.

How do unified APIs compare for verification?

Unified.to is the only one of these five platforms whose API orders checks from verification providers; Kombo's Assessment & Background Check API carries orders from ATSs to check vendors, and Finch, Merge and Apideck have no verification API (competitors as of 8 October 2026; Unified.to as of 1 October 2026).

• Finch fits employment and payroll records only; its reads return the last successful sync.
• Kombo fits an assessment or background-check vendor that wants customers' ATSs to send it orders.
• Merge and Apideck fit multi-category integrations that don't include verification.
• Identity providers such as Socure and Trulioo each have their own API; both are also Unified.to Verification API integrations.

How does Unified.to's Verification API work?

Unified.to's Verification API models every check with two objects: a package is a check a provider offers, and a request is one ordered check with its result. As of 19 October 2026:

• Packages are read-only. List works on every integration with package support (all except SambaSafety, Tazworks and Verified Credentials, which have no package object); retrieve works on Accurate, Checkr, Harver, IDfy, IDmission, Socure and Verified First. A package carries its type, parameters (questions typed as text, number, date, choice or file), valid_regions, needs_ip_address and max_score.
• Requests can be created on every Verification integration except Makesure. Update works on Certn, Checkr and Yardstik; remove on Checkr, TrustID, Verifiable, Yardstik and Zinc. List and retrieve vary by provider (Socure and Verified First support create only), so check the integration support table.
• Provider fields outside the model are available through the raw field and the raw list parameter.

Does Unified.to return current verification status?

Unified.to reads verification requests from the provider at request time, so retrieving a request returns the provider's current status, not a stored copy. Change events, as of 20 October 2026:

• Native webhooks on requests: Accurate, Checkr, SambaSafety, Sterling, Sterling Check, Tazworks, TrustID, Verifiable, Verified First, Yardstik and Zinc.
• Virtual webhooks on requests (Unified.to checks the provider on an interval, down to 1 minute on paid plans): TrustID, Verifiable, Yardstik and Zinc.
• Package change events: Checkr (native).

Both webhook types are set up through the same webhook object. For a provider with no request events, retrieve the request by ID, or list requests with updated_gte where list is supported.

What does Unified.to store from verification data?

Unified.to stores no customer records at rest, so verification data such as dates of birth, addresses, national identifiers and reports passes to your application without a copy held at Unified.to. What it does keep: connection credentials, encrypted at rest, and API call logs with operational metadata only, no request or response bodies (security). If you need to keep results, store them in your own database.

Can the same platform cover ATS and HR data?

Yes: Unified.to also has ATS and HR & Directory APIs, and a verification request's candidate_id points to an ATS candidate, so one hiring flow can read the candidate, order the check and update the application. Unified.to covers 1867 integrations across 37 categories.

When is Unified.to the right choice for verification?

Unified.to fits when your product orders checks from more than one verification provider and also needs ATS or HR data, for example:

• Recruiting or hiring platforms
• HR or onboarding systems
• Contractor or marketplace platforms
• Compliance or risk tools
• AI products that read check status at request time

When should you choose something else?

• Finch, if you only need HRIS and payroll records and reads from its last sync are acceptable (as of 8 October 2026).
• Kombo, if you sell assessments or background checks and want customers' ATSs to send you orders (as of 8 October 2026).
• A direct provider integration, if every customer uses the same verification provider: one provider API with no normalization layer may be simpler.

To compare unified API platforms across every category, see Best Unified API Platforms of 2026.

→ Start your 30-day free trial

→ Book a demo

Written by Mallory Greene.

About the author: Mallory Greene is Head of Marketing at Unified.to_. She writes about integration infrastructure, unified APIs, and MCP for technical teams. Based in Toronto._