We've built integrations with Greenhouse, Lever, and Ashby. Not theoretical integrations — working ones, tested against real candidate pipelines. Each of the three has a meaningfully different architecture for how it handles webhook events, scorecard field structures, and candidate stage transitions. If you're choosing your first ATS or evaluating a switch, those differences matter more than the feature comparison tables suggest.
This isn't a sponsored comparison. We work with all three, we've hit real edges in all three, and we'll tell you what we actually found.
How Each ATS Handles Webhook Events
Webhook architecture is the first thing we look at when building a verification layer integration, because it determines how reliably Proofglint can receive stage transition signals and push scorecard data back into the candidate record without manual intervention.
Greenhouse uses a mature webhook system with a well-documented event payload structure. The `candidate_stage_change` event fires reliably and includes the candidate ID, the stage ID, and the job ID. That's enough to trigger a Proofglint verification flow automatically when a candidate enters a target stage. The Greenhouse API also supports writing scorecard entries directly to the candidate record via the `POST /scorecards` endpoint — which means verification scores show up natively in the Greenhouse scorecard UI, not in a custom field or attached document. Setup time for a working Proofglint-Greenhouse integration in our experience: about 90 minutes for a team with basic API familiarity.
Lever also supports webhooks, but the event schema is structured differently. Lever fires a `candidateStageChange` event, but the payload uses different field naming conventions and requires a secondary API call to retrieve the full candidate object. That's not a blocker — it just means the integration layer needs to handle an extra request. The more significant difference is that Lever's scorecard model is less granular than Greenhouse's. Lever stores feedback as free-text notes with an overall rating, rather than per-criterion scored fields. For teams using Proofglint's structured scorecard output, this means scores push into Lever as a formatted feedback note rather than a native multi-criteria scorecard. The data is all there, but the visual presentation in Lever's UI is different from what you see in Greenhouse.
Ashby is the newest of the three and has the most modern API design. Webhooks in Ashby fire quickly and the payload is well-structured. Ashby also has the most flexible custom field model of the three — you can create typed fields on candidate records that accept structured data, which means Proofglint scores can push into purpose-built fields rather than being embedded in a note. For teams that want clean, queryable verification data in their ATS, Ashby's model is the most accommodating. The tradeoff is that Ashby's ecosystem is smaller, and if you're evaluating integrations beyond Proofglint, you may find fewer ready-built connectors compared to Greenhouse or Lever.
Scorecard Field Structure Comparison
The way each ATS models scorecard fields directly affects how structured verification output lands in the candidate record. Here's how the three platforms compare on the dimensions that matter most for verification workflows:
| Feature | Greenhouse | Lever | Ashby |
|---|---|---|---|
| Native per-criterion scorecard fields | Yes (typed, visible in UI) | No (free-text notes + overall rating) | Via custom fields (flexible but manual setup) |
| Webhook reliability | High, mature | High, minor payload quirks | High, modern design |
| Score visibility in ATS UI | Native scorecard view | Feedback note view | Custom field view |
| API rate limits (approx.) | 500 req/min per key | 300 req/min per key | 250 req/min per key |
| Stage transition trigger for auto-send | Yes, reliable | Yes, requires secondary call | Yes, reliable |
Which ATS Pairs Best With Structured Verification?
If your primary goal is having structured verification scores show up visibly and natively inside your ATS scorecard view — in a format that hiring managers can read without leaving the ATS — Greenhouse has the tightest native fit. The scorecard model maps well to multi-criteria verification output, and hiring managers don't need to know anything about the integration to benefit from it.
If your team is already on Lever and happy with it, the integration works — it just presents differently. Hiring managers see a well-formatted feedback note with all the Proofglint scores, but it's a note, not a structured scorecard panel. For teams that primarily use the overall hiring recommendation rather than comparing per-criterion scores across candidates, this distinction matters less.
Ashby is worth a closer look if you're choosing an ATS fresh and you expect your hiring stack to evolve. The custom field model gives you more control over how data surfaces in the UI, and Ashby's pipeline analysis tools are more mature than Lever's at the data-team level. The tradeoff is that some of that custom field configuration requires a one-time setup investment that Greenhouse doesn't require for the same outcome.
Our honest take: if you're already on one of the three and your team is happy with it operationally, the ATS integration decision isn't worth a platform migration. Proofglint works well with all three. If you're starting fresh and structured scorecard visibility is a top priority, Greenhouse's native model is the most immediate fit.
Practical Setup Considerations
A few operational details that don't show up in feature comparison tables but come up regularly when teams are setting up for the first time:
- OAuth vs. API key — Greenhouse and Ashby support both OAuth and API key authentication for third-party integrations. Lever currently requires API key authentication for most integration patterns. If your IT or security team has preferences about OAuth flows, factor this in.
- Stage naming conventions — Proofglint auto-send triggers on specific stage names in your ATS pipeline. If your Greenhouse or Lever instance has custom stage names (many do), you'll need to confirm those names match the trigger configuration during setup. This is a ten-minute step, but teams that skip it end up with flows not sending when expected.
- Candidate deduplication — If a candidate applies to multiple roles simultaneously, all three ATSs handle this differently. Greenhouse links candidates to multiple job posts as separate applications; Lever and Ashby have their own merge logic. We've built Proofglint's deduplication layer to handle all three patterns, but it's worth reviewing your ATS configuration if you hire at high volume for the same role type across multiple open positions.
Switching ATSs Because of an Integration
One more thing worth naming directly: don't switch ATSs because of a single integration. We've talked to hiring teams who were seriously considering moving from Lever to Greenhouse primarily to get a cleaner scorecard presentation for Proofglint output. That's not a sufficient reason to switch platforms. The implementation cost, the retraining, the data migration — those are real, and the scorecard presentation difference is cosmetic enough that a well-designed integration note accomplishes the same business goal.
Switch ATSs when the platform fundamentally doesn't fit your hiring workflow at scale — not when a third-party integration produces a slightly different visual output. The integrations exist to fit your process, not the other way around.
If you're currently evaluating all three and want to talk through how Proofglint's verification layer connects to your specific ATS configuration, we're happy to walk through the technical details with your recruiting ops team before you commit to a setup direction.
