# 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.

<table><thead><tr><th width="157.1666259765625"></th><th>V1 (current)</th><th>V2 (new)</th></tr></thead><tbody><tr><td><strong>Endpoint</strong></td><td><code>POST /public/ichra/off_ex</code></td><td><code>POST /public/ichra/v2/off_ex</code></td></tr><tr><td><strong>Status</strong></td><td>Live</td><td>Coming soon</td></tr><tr><td><strong>Behavior</strong></td><td>302 redirect to HealthSherpa UI</td><td>Same (302 redirect)</td></tr><tr><td><strong>Authentication</strong></td><td><code>x-api-key</code> header (optional in prod)</td><td>Same</td></tr></tbody></table>

***

### What's New in V2

#### New Field Categories

These are entirely new sections that V1 does not support:

<table><thead><tr><th width="254.93328857421875">Section</th><th>What it prefills</th></tr></thead><tbody><tr><td><strong>Attestations</strong></td><td>Issuer attestations, broker signature attestation, electronic signature consent, disclosure, pediatric dental, agent submitted application, consumer working with agent</td></tr><tr><td><strong>Signatures</strong></td><td>Primary signature, spouse signature, pediatric dental signature, translator signature, and associated dates</td></tr><tr><td><strong>Communication preferences</strong></td><td>Email/call/text notification toggles, marketing consent, HSA opt-in, preferred communication method</td></tr><tr><td><strong>Responsible party</strong></td><td>Name, address, phone, relationship (for applicants who need a responsible party)</td></tr><tr><td><strong>Translator</strong></td><td>Name, language, reason, signature</td></tr><tr><td><strong>Payment method</strong></td><td>Bank account or credit card. Conditionally required for Cigna; can pre-populate for Elevance post-enrollment</td></tr></tbody></table>

#### Expanded Existing Fields

These sections exist in V1 but are expanded in V2:

<table><thead><tr><th width="175.5333251953125">Section</th><th width="242.933349609375">V1</th><th>V2 additions</th></tr></thead><tbody><tr><td><strong>Agent of record</strong></td><td>Name, NPN, CPC, TIN, email, phone, state license</td><td>Address, fax, signature. TIN removed; Elevance identifier moves to <code>carrier_producer_code</code></td></tr><tr><td><strong>Guardian</strong></td><td>Name, gender, relationship</td><td>Email, phone</td></tr><tr><td><strong>Existing coverage</strong></td><td>Has coverage, type, insurer, policy ID, term date</td><td>Policyholder name, start date, will continue</td></tr><tr><td><strong>HRA / Employer</strong></td><td>Name, phone, address, FEIN, contribution, start</td><td>FIPS code, used for spousal/family premiums, annual household income determination</td></tr><tr><td><strong>Primary applicant</strong></td><td>Name, DOB, gender, SSN, citizen, tobacco, race/ethnicity, language</td><td>ITIN, married, student status, graduation date, disability, Medicare/Medicaid enrollment, veteran/military, incarceration, immigration status, tobacco N/A, requesting coverage flag</td></tr><tr><td><strong>Dependents</strong></td><td>Name, DOB, gender, SSN, citizen, tobacco, race/ethnicity</td><td>ITIN, email, phone, external ID, language, married, student, disability, Medicare/Medicaid, alternate address, expanded relationships (parent, stepparent, parent-in-law, sibling, other)</td></tr></tbody></table>

***

### 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.

<table><thead><tr><th width="340.433349609375">What changes</th><th>What stays the same</th></tr></thead><tbody><tr><td>Request body structure (nested objects)</td><td>Endpoint behavior (POST, 302 redirect)</td></tr><tr><td>Field names (<code>street_address</code> becomes <code>street_address_1</code>)</td><td>Authentication (<code>x-api-key</code>)</td></tr><tr><td>Spouse/domestic partner location (into dependents)</td><td>SEP reason enum values</td></tr><tr><td>HRA location (top-level)</td><td>Race/ethnicity and Hispanic origin enums</td></tr><tr><td>Agent fields (nested object)</td><td>Same HealthSherpa-hosted UI experience</td></tr></tbody></table>

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](https://docs.ichra.healthsherpa.com/coming-soon/expanded-deeplink-api/deeplink-mapping).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.ichra.healthsherpa.com/coming-soon/expanded-deeplink-api.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.