Understanding the Paychex integration
Last updated: July 29, 2026
Paychex doesn't open its API to third parties, so Onboarded moves new hire data into Paychex through a scheduled flat file export instead of a real-time connection. This article explains how that handoff works, what's confirmed today, and what's still being built.
This integration is still in build. There's no configuration screen for it yet. The details below reflect Onboarded's current design and what the integrations team has confirmed so far — treat the specifics on field coverage, error handling, and timing as directional until they're validated against an account's actual Paychex flat file template.
What it is
The Paychex integration will export new hire data out of Onboarded on a schedule and drop it as a file for Paychex to pick up and import — the same pattern payroll systems have used for decades, sometimes called a flat file export. It's not an API integration: Paychex has told prospective joint customers it won't open API access, so there's no live, field-by-field sync the way there is with an API-based connection like ADP Workforce Now.
Onboarded already built the underlying file-export engine for ADP flat file customers (ADP Workforce Now and ADP Vantage). Extending that same engine to Paychex is mostly a mapping exercise — teaching it the shape of Paychex's import file — rather than building new technology from scratch.
Why it matters
If your account runs an ATS like Lever alongside Paychex for payroll, and Paychex won't grant API access, a flat file export is the path to get new hire data from Onboarded into Paychex without re-keying it. Understanding how it works matters because a file-based handoff behaves differently than an API integration: it runs on a schedule instead of instantly, and responsibility for finishing a worker's Paychex record is split between what the file carries and what Paychex still expects the account to enter directly.
How it works
Where the handoff happens
Data flows from Lever (or another ATS) into Onboarded during onboarding, then from Onboarded into Paychex on a schedule — not the moment a new hire finishes their tasks. Onboarded generates the file, delivers it, and Paychex imports it on its own timeline from there.
The file is expected to carry the categories Onboarded already collects during onboarding: legal name, address, Social Security number, I-9 outcome, and the tax withholding forms that match the new hire's work state — a Nevada hire only needs a federal W-4, while a Colorado or California hire also completes that state's withholding form. EEO information can be included if an account wants it, but Onboarded typically keeps EEO answers inside the ATS rather than passing them downstream, since a payroll admin doesn't need them day to day.
What isn't confirmed yet is how much of the record that leaves a new hire fully set up for payroll versus how much still requires action inside Paychex directly — things like direct deposit, benefits elections, and emergency contacts. Which of those fields Paychex's flat file import actually accepts is set per Paychex account, since Paychex customizes what its import template supports for each customer. Confirming that requires the account's actual Paychex flat file template, which Paychex can provide directly (usually by asking Paychex for its "flat file import requirements" or template). Until that template is in hand for a given build, plan on some new hire action still happening inside Paychex after the file lands.
What happens if a record doesn't match Paychex's format
The exact error-handling workflow for Paychex specifically is one of the pieces still being finalized — it depends on the data transformations and validations the account's Paychex template requires, which aren't fully known until that template is mapped. That said, it follows the same pattern Onboarded uses on other flat file exports: validation happens on both ends. Onboarded checks its own required fields before including a record in the file, and Paychex's import applies its own template rules once the file arrives.
Whether a bad record fails on its own or takes the whole file down with it, and who gets notified when that happens, depends on how Paychex's specific import behaves — this hasn't been tested against a live Paychex account yet. Onboarded's other flat file builds are designed around per-record handling, where one bad record doesn't block the rest of the file, with the internal implementation team notified to fix the source data and re-send. The Paychex build is expected to follow that same approach.
What setup takes on the technical side
Flat file delivery for Onboarded's other payroll exports uses SFTP, with files encrypted using PGP. The Paychex build is expected to follow the same pattern. Because Onboarded pushes the file out rather than Paychex reaching in, this typically doesn't require inbound firewall changes on the account's side — the specific delivery destination (a Paychex-owned SFTP endpoint versus a shared transfer location) and any account-side network allowlisting get confirmed during implementation.
A Paychex rep does need to be involved, because the account's Paychex flat file import template — the actual document describing what fields Paychex will accept and in what format — has to come from Paychex. That template is the one piece Onboarded can't generate on its own.
There's no confirmed setup timeline yet, since it starts the clock only once that template is in hand. Once Onboarded has a real example file to map against, the team's working estimate is roughly one to two months to build and test the export for that account.
Delivery frequency is configurable rather than fixed. Onboarded's job infrastructure can technically run more often than once a day, but the team lands on a cadence based on the account's actual onboarding volume and on keeping load reasonable on Paychex's SFTP endpoint — daily or a few times a day is typical, and an empty run (no new hires that cycle) is normal and expected.
Email deliverability for candidate-facing messages isn't part of this integration
If your ATS (like Lever) sends candidate-facing emails — offer letters, interview scheduling — from your own domain, authorizing that in your SPF record and setting up DKIM signing is a configuration on your ATS side, not something the Paychex integration touches. Your ATS provider's support team can give you the exact DNS entries to add. Onboarded's own onboarding emails to candidates are a separate step that happens after hire, and if you also want those sent from your own domain, that's Onboarded's own domain verification process — a different set of DNS records from your ATS's.
Example
Take an account that hires through an ATS and runs payroll on Paychex Flex. A new hire completes their I-9 and tax withholding forms inside Onboarded. On the next scheduled export — say, once a day — Onboarded generates a file with that new hire's name, address, SSN, I-9 outcome, and completed tax forms, encrypts it, and delivers it over SFTP. Paychex picks up the file on its own schedule and creates the worker record from it. Depending on what the account's Paychex template supports, the new hire (or the account's payroll admin) may still need to go into Paychex directly to finish direct deposit and benefits elections before that worker is fully ready for their first payroll run.