Your platform is the system of record for who works where. Census sync keeps Prescience matched to it with three operations:
| Event in your system | Call |
|---|
| New hire | POST /groups/{groupId}/members |
| Employee change (ZIP, name, dependents…) | PATCH /groups/{groupId}/members/{memberId} |
| Termination / COBRA | PATCH /groups/{groupId}/members/{memberId} with status: "terminated" |
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.
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
curl -X POST https://www.getprescience.com/api/partner/v1/groups/grp_8c2f41d09a3e/members \
-H "Authorization: Bearer $PRESCIENCE_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: hire-emp_0013" \
-d '{
"externalId": "emp_0013",
"firstName": "Omar",
"lastName": "Haddad",
"email": "omar@acme.com",
"dob": "1994-08-23",
"zip": "94117",
"employmentType": "full_time",
"hireDate": "2026-11-02"
}'
{
"memberId": "mem_5e1da8c47f92",
"externalId": "emp_0013",
"firstName": "Omar",
"lastName": "Haddad",
"email": "omar@acme.com",
"dob": "1994-08-23",
"zip": "94117",
"employmentType": "full_time",
"hireDate": "2026-11-02",
"status": "active"
}
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 upserts by email, so re-pushing the whole roster on a nightly job is a valid (if blunter) sync strategy. Mind the census write limit of 20/min.
Updates
PATCH sends only the fields that changed:
curl -X PATCH https://www.getprescience.com/api/partner/v1/groups/grp_8c2f41d09a3e/members/mem_c4a91f27e83d \
-H "Authorization: Bearer $PRESCIENCE_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "zip": "94611" }'
Address moves, name changes, dependent additions: 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 if the employee elected (or may elect) COBRA continuation:
curl -X PATCH https://www.getprescience.com/api/partner/v1/groups/grp_8c2f41d09a3e/members/mem_92e4b7a1d0c6 \
-H "Authorization: Bearer $PRESCIENCE_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "status": "terminated", "terminationDate": "2026-11-15", "cobra": true }'
{
"memberId": "mem_92e4b7a1d0c6",
"externalId": "emp_0009",
"firstName": "Tom",
"lastName": "Becker",
"email": "tom@acme.com",
"dob": "1974-02-27",
"zip": "94110",
"employmentType": "full_time",
"hireDate": "2022-01-10",
"status": "terminated",
"terminationDate": "2026-11-15",
"cobra": true,
"dependents": [ { "relationship": "spouse", "dob": "1976-05-19", "name": "Anja Becker" } ]
}
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 COBRA: Prescience runs the continuation workflow (election notices, member billing, the coverage window). The roster shows
status: "cobra" with cobra.until, and the member stays covered with no COBRA work on your side or the employer’s.
Terminated members are excluded from quoting immediately; pre-enrollment, a re-quote after a termination reflects it on the next POST /quotes.
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.