EnrollConnect API Specification

Overview

The EnrollConnect API provides full lifecycle control over off-exchange enrollment applications, from creation through carrier submission, status tracking, and post-submission actions (cancel, terminate).

For implementation details, worked examples, and step-by-step integration instructions, see the EnrollConnect Guide.

The request schema below is the canonical application schema shared with the Deeplinks V2 API. Build your payload once and route it to either endpoint based on the Enrollment Decision Path.


Base URLs

Environment
Base URL

Staging

https://api.ichra-staging.healthsherpa.com

Production

https://api.ichra.healthsherpa.com

Authentication uses the x-api-key header for all endpoints.

Rate Limits

Scope
Limit

Per authenticated API key

50 requests per minute

Exceeding the limit returns 429 Too Many Requests with a retry_after value (in seconds) in the JSON response body.


Error Format

All error responses, whether from validation, authentication, or system errors, return a consistent structure:

{
  "errors": [
    {
      "code": "missing_required_field",
      "field": "applicants.primary.ssn",
      "message": "Primary applicant SSN is required for submission"
    }
  ]
}

Each entry in the errors array contains:

Property
Required
Description

code

Yes

Machine-readable enum. Switch on this value rather than parsing message strings.

message

Yes

Human-readable description. May change over time; do not rely on exact wording.

field

No

Dot-path to the offending request field. Present only for field-level validation errors.

The errors array returned on every POST, PUT, and GET response uses the same structure. When this array is empty, the application is ready to submit.

See the EnrollConnect Guide for the full list of error codes and recommended handling patterns.


Hypermedia Actions (next_actions)

Every application response includes a next_actions array containing the available operations for the application in its current state. Each entry provides the relation type, URL, and HTTP method so your platform can drive the workflow without hardcoding URLs.

Property
Required
Description

rel

Yes

Relation type: self, update, validate, submit, cancel, terminate, payment_redirect, upload_supporting_documentation

href

Yes

Relative URL for the action

method

Yes

HTTP verb (GET, PUT, POST)

required

No

When true, this action is a submission prerequisite that must be completed before submit will succeed

The array is state-aware — it changes based on policy_status and carrier capabilities:

Application state
Available actions

draft (pre-submission)

self, update, validate, submit, upload_supporting_documentation, payment_redirect (if carrier supports it)

pending_effectuation

self, cancel, payment_redirect (if carrier supports it)

effectuated

self, cancel, terminate

cancelled / terminated

self

Submission readiness

Use errors and next_actions together to determine if an application is ready to submit:

  1. errors is empty → the application data is valid (all field-level issues resolved)

  2. No next_actions entries have required: true → all prerequisite steps are done (documentation uploaded, payment completed, etc.)

  3. Both conditions met → the application can be submitted

This keeps the distinction clean: errors is for data issues fixable via PUT, while required actions are steps that need separate API calls.

Use rel values to determine what to show in your UI rather than hardcoding endpoint paths.


Future Functionality

The initial release covers the core application lifecycle: create, update, submit, retrieve, cancel, and terminate. The following endpoints are planned as fast-follow additions:

Functionality
Description

PUT /api/v1/applications/:id/payment_method

Set or update payment method independently of a full application update. Required for carriers like Cigna and Elevance that require payment before or with submission

GET /api/v1/applications

Paginated list with filters (status, plan, updated_since) for bulk status polling

PATCH /api/v1/applications/:id

Partial update support. To start, PUT will require the complete payload.

Enrollment requirements on plan lookup

GET /plans/:hios_id?plan_year= will include an enrollment_requirements object with required fields, conditionally required fields, and payment/SEP metadata per carrier.

These endpoints are included in the spec below as a preview. Schemas and behavior are subject to change.

Payment and PCI Compliance

Payment information is managed exclusively through PUT /api/v1/applications/:id/payment_method, not through the application create or update endpoints. This separation ensures a clean PCI boundary.

Sensitive payment fields (credit card number, CVV, bank account and routing numbers) must be sent through a PCI-compliant proxy rather than directly to the API. HealthSherpa will provide a proxy route URL per environment. Your platform sends payment data to this URL; the proxy tokenizes sensitive fields in transit before they reach HealthSherpa. This keeps both your platform and HealthSherpa out of PCI scope.

The GET /api/v1/applications/:id response includes a payment object with carrier-reported payment data (status, paid-through date, balance due, autopay indicator) when available. For carriers that use payment redirect, this data depends on the carrier reporting it back. Sensitive payment method values are never returned in any API response.

Details on the proxy URL, supported fields, and integration steps will be provided when these capabilities are available.


API Specification

Create application

post

Creates a new enrollment application in draft state. Payment information is managed separately via PUT /api/v1/applications/{id}/payment_method.

Authorizations
x-api-keystringRequired

API key provided during onboarding.

Body

Canonical application schema. This schema is shared between the EnrollConnect API (POST /api/v1/applications) and the Application Deeplink (POST /public/ichra/off_ex). Build your payload once and send it to either endpoint.

external_idstringOptional

Your unique identifier for this application.

Example: partner_app_001
_agent_idstringOptional

HealthSherpa-provided agent identifier (slug). Required for deeplink; optional for API if using TPA auth.

Example: your_agent_slug
tpa_slugstringOptional

HealthSherpa-assigned TPA identifier (provided during onboarding).

Example: your_tpa_slug
plan_hios_idstringRequired

14-character HIOS plan ID.

Example: 12345AB6780001
plan_yearintegerRequiredExample: 2026
desired_effective_datestring · dateOptional

Requested effective date. Actual date determined by SEP/OEP rules.

Example: 2026-01-01
american_indian_or_alaskan_native_in_householdbooleanOptional
Responses
post
/api/v1/applications

Update application

put

Full replacement of application state. Partial updates are not supported. Applications can only be updated before submission.

Authorizations
x-api-keystringRequired

API key provided during onboarding.

Path parameters
idstringRequired

HealthSherpa application ID.

Example: HSA000000001
Body

Canonical application schema. This schema is shared between the EnrollConnect API (POST /api/v1/applications) and the Application Deeplink (POST /public/ichra/off_ex). Build your payload once and send it to either endpoint.

external_idstringOptional

Your unique identifier for this application.

Example: partner_app_001
_agent_idstringOptional

HealthSherpa-provided agent identifier (slug). Required for deeplink; optional for API if using TPA auth.

Example: your_agent_slug
tpa_slugstringOptional

HealthSherpa-assigned TPA identifier (provided during onboarding).

Example: your_tpa_slug
plan_hios_idstringRequired

14-character HIOS plan ID.

Example: 12345AB6780001
plan_yearintegerRequiredExample: 2026
desired_effective_datestring · dateOptional

Requested effective date. Actual date determined by SEP/OEP rules.

Example: 2026-01-01
american_indian_or_alaskan_native_in_householdbooleanOptional
Responses
chevron-right
200

Application updated

application/json
application_idstringOptionalExample: HSA000000001
external_idstringOptionalExample: 000001
tpa_slugstringOptionalExample: your_tpa_slug
policy_statusstring · enumOptional

draft when the application has not yet been submitted. Transitions to pending_effectuation on successful submission.

Example: draftPossible values:
document_statusstring · enum · nullableOptional

SEP document verification status. none_needed: no documentation required. required: documentation required but not yet uploaded. uploaded: documentation uploaded, pending verification. verified: documentation verified. denied: documentation denied.

Example: none_neededPossible values:
sep_reasonstring · nullableOptionalExample: offered_ichra
created_atstring · date-timeOptionalExample: 2026-01-14T15:34:00Z
updated_atstring · date-timeOptionalExample: 2026-01-14T15:34:00Z
submitted_atstring · date-time · nullableOptional
desired_effective_datestring · dateOptionalExample: 2026-02-01
plan_hios_idstringOptionalExample: 12345AB6780001
plan_yearintegerOptionalExample: 2026
issuer_hios_idstringOptionalExample: 12345
applicationobjectOptional

Echo of the application data as stored.

put
/api/v1/applications/{id}

Get application

get

Full application record including policy status, payment instructions, and carrier data.

Authorizations
x-api-keystringRequired

API key provided during onboarding.

Path parameters
idstringRequired

HealthSherpa application ID.

Example: HSA000000001
Responses
chevron-right
200

Application details

application/json
application_idstringOptionalExample: HSA000000001
external_idstringOptionalExample: 000001
tpa_slugstringOptionalExample: your_tpa_slug
policy_statusstring · enumOptional

draft when the application has not yet been submitted. Transitions to pending_effectuation on successful submission.

Example: draftPossible values:
document_statusstring · enum · nullableOptional

SEP document verification status. none_needed: no documentation required. required: documentation required but not yet uploaded. uploaded: documentation uploaded, pending verification. verified: documentation verified. denied: documentation denied.

Example: none_neededPossible values:
sep_reasonstring · nullableOptionalExample: offered_ichra
created_atstring · date-timeOptionalExample: 2026-01-14T15:34:00Z
updated_atstring · date-timeOptionalExample: 2026-01-14T15:34:00Z
submitted_atstring · date-time · nullableOptional
desired_effective_datestring · dateOptionalExample: 2026-02-01
plan_hios_idstringOptionalExample: 12345AB6780001
plan_yearintegerOptionalExample: 2026
issuer_hios_idstringOptionalExample: 12345
applicationobjectOptional

Echo of the application data as stored.

get
/api/v1/applications/{id}

List applications (stretch for launch)

get

Paginated list of applications. Supports filtering by status, plan, and timestamps. This endpoint is a stretch goal for the initial launch and may be available shortly after.

Authorizations
x-api-keystringRequired

API key provided during onboarding.

Query parameters
policy_statusstring · enumOptionalPossible values:
external_idstringOptional
plan_yearintegerOptionalExample: 2026
issuer_hios_idstringOptionalExample: 12345
plan_hios_idstringOptionalExample: 12345AB6780001
employer_external_idstringOptional

Filter by the employer's external identifier.

updated_sincestring · date-timeOptional

ISO 8601. Returns applications updated after this time.

limitinteger · max: 100OptionalDefault: 25
offsetintegerOptionalDefault: 0
Responses
chevron-right
200

List of applications

application/json
get
/api/v1/applications

Upload supporting documentation

post

Upload a document to support SEP eligibility. Some carriers require documentation for certain SEP reasons before coverage is effectuated. Use GET /applications/{id} to check document_status.

Authorizations
x-api-keystringRequired

API key provided during onboarding.

Path parameters
idstringRequired

HealthSherpa application ID.

Example: HSA000000001
Body
filestring · binaryRequired

The document file (PDF, JPEG, or PNG).

document_typestringOptional

Type of supporting document being uploaded.

Example: sep_verification
Responses
post
/api/v1/applications/{id}/supporting_documentation

Submit application

post

Submits the application to the carrier. Transitions to pending_effectuation. Application becomes read-only after submission. Check errors on the application response before calling. Submission will fail with 422 if there are outstanding errors.

Authorizations
x-api-keystringRequired

API key provided during onboarding.

Path parameters
idstringRequired

HealthSherpa application ID.

Example: HSA000000001
Responses
chevron-right
200

Application submitted, now pending effectuation

application/json
application_idstringOptionalExample: HSA000000001
external_idstringOptionalExample: 000001
plan_yearintegerOptionalExample: 2026
plan_hios_idstringOptionalExample: 12345AB6780001
policy_statusstringOptionalExample: pending_effectuation
submitted_atstring · date-timeOptionalExample: 2026-01-14T16:00:00Z
post
/api/v1/applications/{id}/submit

Get payment redirect data

get

Returns the data needed to redirect the user to the carrier's payment page. The response includes the carrier endpoint URL, the HTTP method, and a set of form fields to include in the request.

The keys and values in fields will vary depending on the carrier's payment integration. Your platform does not need to interpret or understand them. Include every returned field exactly as provided. Build a form POST to the returned endpoint with the returned fields as hidden inputs and submit it in the user's browser.

This is the primary payment path for most off-exchange carriers. Check payment_instructions.payment_redirect_supported on the application response to determine if this endpoint applies.

Authorizations
x-api-keystringRequired

API key provided during onboarding.

Path parameters
idstringRequired

HealthSherpa application ID.

Example: HSA000000001
Responses
chevron-right
200

Payment redirect data returned

application/json
application_idstringOptionalExample: HSA000000001
methodstring · enumOptional

HTTP method to use. Always POST.

Example: POSTPossible values:
endpointstring · uriOptional

The carrier's payment URL. Submit the form POST to this URL.

Example: https://carrier.example.com/payments
get
/api/v1/applications/{id}/payment_redirect

Cancel application

post

Cancels an application that is pending effectuation. Not all carriers support cancellation. Use the GET /applications/{id} response to check carrier capabilities.

Authorizations
x-api-keystringRequired

API key provided during onboarding.

Path parameters
idstringRequired

HealthSherpa application ID.

Example: HSA000000001
Body
reasonstringOptional

Reason for cancellation.

effective_datestring · dateOptional

Requested cancellation effective date.

Responses
chevron-right
200

Application cancelled

application/json
application_idstringOptionalExample: HSA000000001
policy_statusstringOptionalExample: cancelled
effective_datestring · date · nullableOptional

The effective date of the status change (cancellation or termination).

Example: 2026-03-01
updated_atstring · date-timeOptionalExample: 2026-02-15T10:30:00Z
post
/api/v1/applications/{id}/cancel

Terminate policy

post

Terminates an active (effectuated) policy. Used when coverage should end before the natural expiration date.

Authorizations
x-api-keystringRequired

API key provided during onboarding.

Path parameters
idstringRequired

HealthSherpa application ID.

Example: HSA000000001
Body
reasonstringOptional

Reason for termination.

termination_datestring · dateRequired

Requested termination effective date.

Responses
chevron-right
200

Termination request accepted

application/json
application_idstringOptionalExample: HSA000000001
policy_statusstringOptionalExample: cancelled
effective_datestring · date · nullableOptional

The effective date of the status change (cancellation or termination).

Example: 2026-03-01
updated_atstring · date-timeOptionalExample: 2026-02-15T10:30:00Z
post
/api/v1/applications/{id}/terminate

Last updated