2025 Growth Unified Hits Major Growth Milestones with 6.5x usage & 4.5x revenue growth
Unified.to
All articles

How to Build Candidate Assessments Across Workday, Greenhouse, Lever, and 60+ ATS Platforms with a Unified API

September 28, 2025

Updated June 2026

Candidate assessment is a core step in hiring. Once an application reaches a defined point — a status like "Reviewing" in an ATS — your product may need to trigger an assessment, collect results, and write them back to the ATS.

Doing this across dozens of applicant tracking systems is where most teams hit friction. Each ATS has its own schema, authentication, and webhook behavior. A unified API removes that by providing normalized candidate, application, job, and document data, fetched directly from the source, plus write support for posting results back.

The same ingestion pattern also powers a semantic matching layer, where resumes and job descriptions are embedded and retrieved at query time to drive ranking, matching, and AI-generated evaluations.

Why candidate assessment requires integrations

ATS platforms are the system of record for candidate and job data. To power assessments, your application needs:

  • Candidate profile and contact details
  • Application status and job context
  • Documents like resumes or portfolios
  • Resume and job-description text to drive semantic matching against a retrieval layer built on ATS data

Assessments often need to be triggered automatically, then scored results written back as scorecards, notes, or custom fields. Without a unified API, you'd build and maintain a separate integration for each ATS — slowing roadmap delivery and creating long-term maintenance overhead.

Normalized candidate data

A unified API standardizes the core ATS objects. On Unified.to, the relevant ones for assessments are:

  • Application (ats_application) — links candidate to job: id, candidate_id, job_id, status, original_status, created_at. The status field maps each ATS's disposition to a normalized enum; original_status preserves the vendor's raw label alongside it.
  • Candidate (ats_candidate) — profile and contact data: id, name, emails, telephones, title, web_url, skills, experiences.
  • Job (ats_job) — requisition record: id, name, description, addresses, employment_type, questions.
  • Document (ats_document) — resumes, portfolios, and supporting files: id, filename, document_url, document_data, candidate_id, application_id.
  • Scorecard (ats_scorecard) — structured evaluation: id, recommendation, comment, questions, interview_id, application_id, candidate_id.

Webhooks — native or managed change detection — deliver changes as they happen, so assessments trigger at the right point in the pipeline.

Data flow for assessments

With Unified.to, the flow is straightforward:

  1. Connect the ATS through Unified.to's embedded authorization.
  2. Fetch ats_application records and filter by status to identify candidates to assess.
  3. Register a webhook for application updates — Unified.to manages native streams and, where the ATS has no native webhook, managed change detection.
  4. Retrieve the related ats_candidate, ats_job, and ats_document records for context.
  5. Run your assessment workflow.
  6. Write results back to the ATS as ats_scorecard records, notes, or custom fields.

This delivers a consistent assessment experience across ATS platforms without a separate build per vendor.

A note on writeback: scorecards, notes, and custom fields are written back across the supported catalog. Stage and status transitions are handled differently from vendor to vendor — read disposition through the normalized status enum, and confirm write behavior per integration in the capability matrix.

Want a deeper dive into implementation patterns? See How to Build a Candidate Assessment Product with Unified.to.

Extending assessments into a semantic matching layer

For AI-driven screening, ranking, or recruiter Q&A, extend this workflow into a retrieval layer:

  1. Subscribe to application create and update webhooks.
  2. Retrieve resumes and job descriptions through ats_document and ats_job.
  3. Chunk the resume and job text and generate embeddings.
  4. Store the embeddings in your own vector database with identifiers like connection_id, candidate_id, job_id, and updated_at.
  5. At evaluation time, retrieve the most relevant resume segments against the job description before generating scores or written feedback.

Unified.to handles ingestion across 85 ATS platforms, fetched live from the source; you own the embeddings and vector storage in your own infrastructure. No candidate data is cached on Unified.to's side.

Supported ATS platforms

Unified.to supports 85 ATS integrations, including:

See the full list of supported ATS integrations.

Why this matters for product teams

For PMs and platform engineers, the value is direct:

  • Trigger assessments consistently across 85 ATS systems without per-vendor logic.
  • Unify candidate and job data into one schema — making it easier to build resume search, semantic matching, and AI-driven screening on a single retrieval layer.
  • Write outcomes back as structured scorecards so recruiters see results in their ATS, with normalized status to read where each application sits.
  • Scale without maintenance — no tokens, retries, or API changes to manage, and no customer data stored.

Start building candidate assessment workflows across 85 ATS platforms today. Sign up for a free 30-day trial or book a demo to see how Unified.to fits your roadmap.

All articles