ATS Integration Best Practices for Verification Workflows

One of the more consistent frustrations we hear from recruiting teams is around the seam between their verification tool and their ATS. Not the verification itself — that part usually works. The friction lives in the handoff: scorecard data sitting in a separate tool that nobody checks because it is not in Greenhouse, or webhooks that fire correctly in staging but silently fail in production, or an integration that works for Lever but breaks when the company switches to Ashby six months later. We built Proofglint's integration layer with those failure modes in mind, and this post covers what we learned.

There are three meaningful patterns for connecting a verification workflow to an ATS. Each has different operational implications, different failure modes, and a different ceiling for how well it can support a high-volume hiring program. Choosing the wrong one is not usually catastrophic — but it creates friction that compounds over time, especially as hiring volume increases.

Pattern 1: OAuth-Based Native Integration

For teams using Greenhouse or Lever, OAuth-based native integration is almost always the right first choice. The recruiter connects their ATS account to Proofglint once, via a standard OAuth flow. From that point on, scorecards push automatically to the candidate record whenever a Proofglint flow is completed — no manual export, no copy-paste, no PDF to attach.

The operational advantage is that the scorecard lives where the hiring team already spends their time. Hiring managers in Greenhouse do not have to check a second system. The Proofglint scorecard appears in the candidate's profile as a structured note with per-criterion ratings, the AI confidence score, and any consistency flags. The ATS pipeline stage logic fires normally — if your Greenhouse setup moves candidates from "Screen" to "Interview" when they receive a positive scorecard, that happens automatically.

The limitation of OAuth-based integration is that it follows the ATS's data model. Greenhouse and Lever both have scorecard field structures that were built around traditional interview scorecards, not async verification flows. Some fields map cleanly — criterion ratings, overall recommendation, notes. Others require mapping decisions: where does the AI confidence score live? How do you represent a consistency flag (a yellow or red marker that a resume claim doesn't match the candidate's response) in a field structure designed for free-text interview notes?

Our approach is to push the structured data to a dedicated Proofglint scorecard section within the ATS candidate record, with the consistency flags encoded as structured tags rather than prose. This keeps the scorecard machine-readable (for reporting) and human-readable (for the hiring manager who opens it). Teams that try to map everything into free-text note fields end up with scorecards that are visually clean but analytically useless — you cannot aggregate free text across 50 candidates to understand where your candidate pool is strongest.

Pattern 2: API Key + Webhook Integration

For teams using Ashby, or for teams whose ATS does not have a native Proofglint integration, API key authentication with outbound webhooks is the standard pattern. Ashby's API is well-documented and reasonably consistent across tenant configurations, which makes it a reliable integration target. The tradeoff is that it requires someone to configure the webhook endpoint, test the payload, and set up error handling for cases where the webhook silently fails.

Webhook reliability deserves more attention than it usually gets. In our experience, the most common failure mode is not the webhook itself but the receiving end — the Proofglint side sends the payload, Ashby receives it, but the mapping between Proofglint scorecard fields and Ashby's candidate record fields was configured to write to a field that was later renamed or deleted in the ATS. The webhook succeeds (HTTP 200) but the data writes to a field nobody checks, or fails silently on a null field reference.

The fix is systematic testing and field-locking. When we configure an Ashby integration, we run a test flow end-to-end with a dummy candidate before going live, and we document which Ashby field each Proofglint data point maps to. If the ATS admin later renames a custom field, that documentation flags the potential breakage before it affects real candidate data.

One practical note: webhook integrations work best when you treat them as a fragile dependency, not a reliable pipe. Set up monitoring for failed payloads, build a manual fallback path (CSV export works for weekly reconciliation), and assign someone to review integration health monthly. Fifteen minutes a month to verify that scorecards are landing correctly is much cheaper than discovering a three-month gap in scorecard data when you are trying to analyze a hiring pipeline.

Pattern 3: CSV Export + Manual Import

CSV export is not a failure mode — it is a legitimate integration pattern for teams with low hiring volume, complex ATS customizations that make native integrations impractical, or a procurement process that delays OAuth connection setup for months after the verification workflow is live.

Proofglint exports scorecards as structured CSV files with one row per candidate, columns for each scored criterion, the AI confidence score, consistency flags, and a plain-text response summary. Most ATSs can import CSV files into candidate records with some mapping configuration. It is not automatic, but for teams running 10 to 20 candidate flows per week, a weekly import takes about 15 minutes.

Where CSV export breaks down is at volume. At 50 or more candidate flows per week, manual import becomes a significant operational burden, and the lag between completion and ATS update (up to a week on weekly import cycles) creates decision delays. The recruiting coordinator is making advance/hold decisions from a Proofglint dashboard that is not in sync with the ATS, which eventually causes scheduling mistakes.

The right time to upgrade from CSV to OAuth or webhook integration is when the import takes more than 30 minutes per week or when scorecard-to-decision lag is causing more than one scheduling mistake per hiring cycle. Both are practical thresholds — not theoretical ones.

The Integration Decision Matrix

What Good Integration Looks Like for the Hiring Manager

When integration is working correctly, the hiring manager should not have to think about it. They open a candidate record in their ATS, see the Proofglint scorecard section, review the per-criterion ratings and any consistency flags, and make their advance/hold decision without leaving the tool. No separate login to a verification portal. No email with a PDF attachment. No Slack message from the recruiter with a summary of what Proofglint said.

The hiring manager sees the structured data in the context where they make decisions. That is the bar. If the hiring manager is doing any translation work between the verification output and their ATS, the integration is not complete — it is a partial automation with a human in the loop at the wrong step.

We have seen teams invest heavily in verification quality and then lose most of the benefit because the scorecard never reliably made it to the decision-maker in a usable form. The verification layer and the ATS integration layer are equally important. Getting one right and not the other produces a hiring workflow that is more work than what it replaced.