Expanded Deeplink API

Coming Soon. V2 is in active development. The current Application Deeplink (V1) continues to work unchanged.


Why V2

The current Application Deeplink supports a subset of application fields. In practice, this means agents still need to manually fill in attestations, signatures, communication preferences, and other fields inside the HealthSherpa UI after landing on the prefilled application.

V2 solves two problems:

  1. More prefill. V2 accepts every field that the off-exchange application supports, so platforms can pre-populate attestations, signatures, payment method, guardian details, responsible party, translator, and more. The closer to a complete application the deeplink lands on, the less manual work for the agent.

  2. Schema alignment with EnrollConnect. V2 uses the same canonical request schema as the upcoming EnrollConnect API. This means platforms that start with the deeplink can migrate to the full API later without restructuring their payload. Build once, route to either path.


No Breaking Changes

V2 is a new versioned endpoint. The current deeplink (POST /public/ichra/off_ex) continues to work exactly as it does today. V1 partners do not need to change anything.

V1 (current)
V2 (new)

Endpoint

POST /public/ichra/off_ex

POST /public/ichra/v2/off_ex

Status

Live

Coming soon

Behavior

302 redirect to HealthSherpa UI

Same (302 redirect)

Authentication

x-api-key header (optional in prod)

Same


What's New in V2

New Field Categories

These are entirely new sections that V1 does not support:

Section
What it prefills

Attestations

Issuer attestations, broker signature attestation, electronic signature consent, disclosure, pediatric dental, agent submitted application, consumer working with agent

Signatures

Primary signature, spouse signature, pediatric dental signature, translator signature, and associated dates

Communication preferences

Email/call/text notification toggles, marketing consent, HSA opt-in, preferred communication method

Responsible party

Name, address, phone, relationship (for applicants who need a responsible party)

Translator

Name, language, reason, signature

Payment method

Bank account or credit card. Conditionally required for Cigna; can pre-populate for Elevance post-enrollment

Expanded Existing Fields

These sections exist in V1 but are expanded in V2:

Section
V1
V2 additions

Agent of record

Name, NPN, CPC, TIN, email, phone, state license

Address, fax, signature. TIN removed; Elevance identifier moves to carrier_producer_code

Guardian

Name, gender, relationship

Email, phone

Existing coverage

Has coverage, type, insurer, policy ID, term date

Policyholder name, start date, will continue

HRA / Employer

Name, phone, address, FEIN, contribution, start

FIPS code, used for spousal/family premiums, annual household income determination

Primary applicant

Name, DOB, gender, SSN, citizen, tobacco, race/ethnicity, language

ITIN, married, student status, graduation date, disability, Medicare/Medicaid enrollment, veteran/military, incarceration, immigration status, tobacco N/A, requesting coverage flag

Dependents

Name, DOB, gender, SSN, citizen, tobacco, race/ethnicity

ITIN, email, phone, external ID, language, married, student, disability, Medicare/Medicaid, alternate address, expanded relationships (parent, stepparent, parent-in-law, sibling, other)


Migration Path

Partners currently on V1 have no urgency to migrate. When ready, the changes are mechanical: restructure the payload to match V2's nested format. No business logic changes.

What changes
What stays the same

Request body structure (nested objects)

Endpoint behavior (POST, 302 redirect)

Field names (street_address becomes street_address_1)

Authentication (x-api-key)

Spouse/domestic partner location (into dependents)

SEP reason enum values

HRA location (top-level)

Race/ethnicity and Hispanic origin enums

Agent fields (nested object)

Same HealthSherpa-hosted UI experience

Partners planning to adopt EnrollConnect should build to the V2 schema from the start. The same payload works for both the deeplink and the API.

For a complete field-by-field reference, including JSON before/after examples for every structural change, see the V1 to V2 Field Mapping Reference.

Last updated