Skip to main content
Your platform is the system of record for who works where. Census sync keeps Prescience matched to it with three operations:
Before enrollment, a census write that changes rating (ages, ZIPs, sex, households or waivers) starts a new market comparison; an unchanged census keeps its current price. This applies to PUT /census, POST /members, PATCH /members/{memberId}, and a PATCH /groups/{groupId} that moves the HQ ZIP. While the comparison runs, POST /quotes returns 409 rates_pending (retry) and the iframe shows its progress. A write’s response reports census acceptance only; it never returns an iframe URL. When an employer later opens the Prescience offer, create a separate POST /groups/{groupId}/embed-sessions request as described in the Bolto iframe guide.
The same calls work before and after enrollment. Before, they edit the quoting census. After, they also propagate to the live company roster; coverage and member invitations follow from there. You don’t change your code at activation. PUT /census replaces the whole census. Before enrollment, members you omit are removed. After enrollment, omission never terminates anyone; terminate with PATCH and status: "terminated".
Hook these calls into the same internal events that drive your payroll changes. If your system emits “employee terminated”, the Prescience sync is one webhook consumer away.

​
New hires

Response (201)
Same member schema as the bulk census. Store the returned memberId against your employee record; it’s the handle for every later update. For an enrolled group, send the full enrollment fields (firstName, lastName, email) up front so the new hire gets their Prescience invitation immediately. Bulk-first is also fine: PUT /census matches by email, so re-pushing the whole roster on a nightly job is a valid (if blunter) sync strategy. Always send everyone; before enrollment, a member left out is removed. Mind the census write limit of 20/min.

​
Updates

PATCH sends only the fields that changed:
Address moves, name changes, status flips: all the same call. In-force pricing doesn’t re-rate mid-year; census changes affect the next renewal.

​
Terminations and COBRA

Terminate with a status change. Set cobra: true when the employee and covered family members are eligible to receive a COBRA offer. This does not elect or activate coverage. A cobra: true termination is rejected with 400 invalid_request unless it includes terminationDate, coverageLossDate, and the household mailing address (mailingAddressLine1, mailingCity, mailingState, mailingPostalCode). qualifyingEventType is optional and defaults to termination; hours_reduction and employee_death are also accepted.
Response (200)
What happens next, for an enrolled group:
  • Without COBRA: coverage ends per the termination date; the member drops from active rating and the roster shows terminated.
  • With continuation eligibility: Prescience creates independent employee/dependent election rights and starts the employer-configured continuation notice workflow (contractual continuation for the current live plans, and federal COBRA only when that applicability is approved). The roster remains terminated while carrier proof, elections, or initial payment are pending. It changes to cobra with cobra.until only after that employee’s carrier proof is verified, Diamond is elected, and the required premium is matched to an incoming Lemma deposit; waivers, lapses, and unpaid elections never count as active coverage.
Keep the covered-dependent roster current on the member. personalEmail is optional (it must be a non-work address); when no usable non-work address and affirmative electronic-delivery consent are on file, Prescience queues a printable paper notice for the employer to mail and confirm. Terminated members are excluded from quoting immediately. Before enrollment, a termination starts a new market comparison; once it finishes, the next POST /quotes reflects it.

​
Confirmation

Census writes are confirmed two ways: the synchronous response you already have, and the census.processed webhook with the same counts (received, accepted, memberCount), useful when the team operating the sync isn’t the team that owns the request path.