Skip to main content
If your platform runs payroll on Check, this page maps Check’s API objects onto the Prescience census schema field by field. The short version: Check natively stores every field the census API requires, so the integration is a data-mapping exercise against records you already hold.
The Prescience Partner API is fully compatible with Check-powered payroll platforms. Names, email, date of birth, ZIP, hire date, and employment status all come straight off Check’s Employee object; legal name, address, and contact details come off Company. Check’s employee.* webhooks give you real-time census-sync triggers, and its benefits API carries employer HSA contributions through payroll with IRS limits enforced.
Check also runs an established third-party benefits integration program (health insurance and retirement providers attach deductions to Check payrolls today), so this integration shape is well-trodden on their side. See Check’s benefits documentation.

​
Employee field mapping

Each census member submitted to PUT /groups/{groupId}/census maps from Check as follows. Field references come from Check’s Employee object.

​
Company field mapping

For POST /groups, from Check’s Company object:

​
What Check does not model

Three census fields live in your application layer rather than in Check. Every benefits provider integrating with Check-powered platforms collects these the same way.
  1. Dependents. Check has no dependents object. Collect spouse and child records (relationship, name, date of birth) in your enrollment UI and include them as dependents[]. Quoting works without them, but premiums for covered dependents only price correctly when they are present.
  2. Sex at birth. Not on Check’s employee object. Optional in our schema.
  3. Full-time vs part-time. Check classifies pay (hourly, salaried) on earnings, not employment class on the employee. Source employmentType from your own HRIS data.
Also note: dob and residence are optional in Check’s schema. Both are required for quoting, so validate them before calling PUT /census. The endpoint returns per-row errors for anything missing, so a dry-run submission doubles as a completeness check.

​
Census sync triggers

Subscribe to Check’s webhook events and forward changes to the census endpoints described in Census sync: Check has no dedicated termination event; terminations surface as employee.updated with termination_date set, so inspect that field in your employee.updated handler.

​
HSA contributions through payroll

The employer chooses at setup to cover between 50% and 100% of each premium, and employees pay the rest through payroll. Read each employee’s share from GET /groups/{groupId}/members (deduction.perPaycheck.employeeCents, with deduction.preTax telling you whether it is a pre-tax Section 125 deduction) and create the matching Check benefit, with deduction.perPaycheck.employerCents as the company contribution for each pay period; see Payroll deductions. For HSA payroll contributions, each employee’s saved election is hsaElection on the same response: set up an hsa benefit with hsa_contribution_limit from hsaElection.contributionLimit, and split hsaElection.targetCents across the employee’s remaining paychecks. Check records the deduction and reduces take-home pay; it does not deposit the money into the employee’s HSA. Prescience does that from your confirmed payroll results. See HSA elections.

​
Sandbox parity

Check’s sandbox and the Prescience test mode compose cleanly: point your Check sandbox employee data at our test-mode endpoints with a psk_test_ key, and the full census, quote, and enrollment flow runs end to end with no live money movement on either side. See Environments.