Skip to main content
The Bolto integration keeps the employer in Bolto through plan discovery, then opens a secure, preloaded Prescience workspace when they choose to continue. Bolto remains the source of truth for payroll demographics. The iframe is a read-only conversion experience, not a second census editor.

Employer experience

  1. Bolto creates the employer group and syncs the census from Check.
  2. Later, when the employer opens the Prescience offer in Bolto, Bolto’s frontend asks Bolto’s backend for an embed session.
  3. Bolto’s backend creates the short-lived session with Prescience and returns the response’s url to Bolto’s frontend.
  4. Bolto renders that URL as the iframe src. The iframe shows animated, company-specific modeling while Prescience compares the group against current local market plans.
  5. The iframe reveals Prescience Diamond with modeled employer cost, annual savings, benefits, network, and the comparison benchmark.
  6. The employer clicks Finish setup on Prescience, verifies a work email with a six-digit code, and clicks Open my workspace.
  7. Prescience creates hosted onboarding and opens a one-use authenticated handoff in a new tab. The employer’s company and census are already loaded.
The email must match the benefits contact on the group or use the group’s company domain. The handoff token expires after five minutes and works once.

1. Create the group and census

Use the normal group and census sync endpoints. Include dependents when Check has them. Those submitted households will drive the model. If Bolto does not yet have dependent elections, Prescience uses a stable, normalized small-group household mix and discloses that assumption in the quote. Final pricing, eligibility, and plan documents are confirmed during underwriting and onboarding.
Those are the only account-creation inputs Bolto needs: employer name, company domain, contact name, and work email. Do not collect a prior PEPM, address, title, or external employer ID for this step. Then replace the census with PUT /groups/{groupId}/census. A census sync that changes rating (ages, ZIPs, sex, households or waivers) starts the market comparison; an unchanged census keeps its current price. Bolto does not need to orchestrate a separate sweep call. While the comparison runs, the iframe shows its progress. The census response contains only census acceptance counts and row errors. It does not contain an iframe URL and it does not open an iframe. Store the returned groupId; Bolto uses it later when an employer opens the offer.

2. Mint the iframe URL from Bolto’s backend

Response (201)
Sessions expire after 30 minutes. Create a fresh session whenever the employer opens or reloads the Prescience offer. Do not persist the iframe URL. Prescience returns the URL to Bolto’s backend. Bolto does not return that URL back to Prescience. Its backend should pass url and expiresAt to its own frontend, which renders the URL. The raw token does not need to be returned as a separate browser field because it is already contained in url.
Never put PRESCIENCE_API_KEY in browser code. Only the short-lived URL returned by POST /embed-sessions may enter the browser.

3. Render it in Bolto

The browser should ask Bolto’s own backend for the session URL, then set it as the iframe src.
Bolto backend
Bolto frontend
Recommended container behavior:
  • Use the full content width. Size the height from the iframe’s resize message; until the first one arrives, start at about 900px on desktop.
  • Give the iframe a dedicated route or full-width drawer, not a small modal.
  • On mobile, use the full viewport width and allow vertical scrolling.
  • If the session expires, request a new session from Bolto’s backend and replace src.
  • Do not overlay Bolto controls on the iframe’s call-to-action or email fields.
Do not create the embed session inside the census-sync handler. Census sync and employer entry are separate operations. An embed session can be created while modeling is still running; the iframe will show live progress and reveal the plan when it is ready.

Look and feel

The iframe is a Prescience product surface, so it always uses Prescience’s brand: grape actions, lavender surfaces and Prescience’s type, on a white background that sits cleanly inside your page. It does not take your colors or font. A theme query parameter or a default theme on your partner record is still accepted, so existing integrations keep working, but it no longer changes how the iframe looks. You don’t need to send one.

Size the iframe to its content

The iframe posts its content height to your page whenever it changes, so you can size the iframe exactly and avoid an inner scrollbar:
Bolto frontend
Messages go only to the iframe origins saved on your partner record, or to the page that framed the iframe once it passes that allowlist.

Iframe sandbox

If you sandbox the iframe, it needs allow-scripts allow-same-origin allow-forms allow-popups. Open my workspace opens Prescience in a new tab, so allow-popups is required; add allow-popups-to-escape-sandbox so that tab isn’t sandboxed too. The iframe never navigates your page, so allow-top-navigation is not needed.

What the iframe calls

These endpoints use the embed token internally. Bolto does not need to call them itself. The iframe polls only while pricing is running. It shows a recoverable error instead of spinning forever if pricing or the estimate fails.

Framing allowlist

Send Prescience every origin that will frame the integration, including exact staging, preview, and production origins. Prescience ops saves these on the Bolto partner record. An origin includes the scheme and hostname, for example:
A trailing slash or path is ignored: https://team.bolto.com/ is the same origin. The iframe document sends a browser-enforced Content-Security-Policy frame-ancestors directive. An unlisted origin is rejected before any employer data renders. https://internal.getprescience.com is separately allowed for Prescience’s own QA page. Live mode requires this list. Until Prescience has saved at least one explicit origin on the partner record, POST /groups/{groupId}/embed-sessions with a live key returns 409 conflict. Sandbox sessions keep working while origins are still being settled.

Bolto acceptance test

Run this sequence with a sandbox key and a synthetic employer of at least 10 employees, each with a date of birth and home ZIP (quotes price every member by age and location, so a one-person census doesn’t test pricing):
1

Authenticate and create the employer

Call GET /ping, create a test group with a valid benefits contact, then PUT /census. Confirm every accepted employee is returned by GET /census.
2

Open the offer from Bolto

Mint an embed session on Bolto’s server and open it from the exact staging origin that will ship. Confirm the API key never appears in browser source, network requests, logs, or the iframe URL.
3

Watch the model complete

Confirm the loading screen names the company, shows real progress (the market comparison takes about two minutes) and the plan’s benefits, and moves to the plan without a manual refresh. Close and reopen the offer: with the census unchanged, it goes straight to the same plan without replaying the loading steps. Confirm failures produce retry and support actions.
4

Validate the offer

Confirm the total cost, the savings against the benchmark (the most expensive platinum PPO quoted for the group, named by its carrier’s logo), the comparison rows and the benefits match the estimate. When the quote is in review (see Quotes in review), confirm the plan shows the total cost with no saving, and the line “Setup opens once Prescience confirms final pricing for your group.” in place of the setup button. Ask Prescience to finalize it, reopen the offer, and confirm setup is now available. Reload and confirm the numbers stay the same for the same stored census and market-rate snapshot.
5

Test the employer handoff

Click Finish setup on Prescience. Confirm a personal-domain email is rejected. Use the group contact or another address on the company domain, enter the six-digit code, and click Open my workspace. Confirm a new tab opens directly to the employer workspace with the correct company and census.
6

Test expiration and replay protection

Try the handoff URL a second time and confirm it no longer creates a session. Let an embed session expire, then confirm Bolto can mint and load a replacement.
7

Verify the enrollment and deductions

Confirm enrollment.created appears on GET /events (and, if you registered a webhook, that it arrived and its signature verifies). Read GET /groups/{groupId}/account and GET /groups/{groupId}/members: the same employer and roster, and after Prescience approves plan terms, each enrolled employee’s deduction.perPaycheck (see Payroll deductions).

Go-live checklist

  • Prescience has Bolto’s staging and production iframe origins.
  • Bolto has separate sandbox and production secrets.
  • Bolto completed the acceptance test above with synthetic data.
  • Prescience turned on live mode.
  • Recommended, not required: Bolto registered and tested a webhook endpoint.
  • Bolto swaps only the secret at launch. The endpoint and payload shapes stay the same.
Prescience tracks these from its records, not by hand: two https origins on your partner record, an active sandbox key, and a sandbox enrollment (the acceptance test’s last step). Production access can’t be turned on until all three are in place and Prescience turns it on; your production key is issued after that. A webhook isn’t required because every event is also on GET /events, and the iframe reads quote and enrollment state itself. Register one if you want to react right away, for example to tell the employer when an in-review quote is finalized (quote.finalized).