This article introduces the Data Exchange Postback, HealthSherpa's webhook integration for sending enrollment and lead data to carrier systems in real time. It is written for carrier technical and operations teams evaluating or implementing the integration.
Postbacks are available to Carrier White Labels and non-issuer hybrid partners. Availability of specific payload types depends on your account configuration. Contact your Technical Account Manager (TAM) to confirm what is enabled for your organization. |
How Postbacks work
With postbacks enabled, HealthSherpa sends data to a webhook endpoint that your team publishes. When a qualifying event occurs on the platform, such as an application submission, HealthSherpa POSTs a structured JSON payload to your endpoint. Carriers can then use this data to keep their CRM current, trigger member communications, or notify their sales team.
Each postback type can be routed to its own endpoint, or you can use a single endpoint for all types. If HealthSherpa receives a 4xx or 5xx response from your endpoint, the postback is automatically retried three times with exponential backoff.
Available postback types
Enrollments (On-Exchange): Sent in real time when an application is successfully submitted.
Eligibility (On-Exchange): Sent in real time on final eligibility determination or when an agent uses Search Marketplace to claim an existing application.
EDE Sync (On-Exchange): Sent when an application syncs with the Marketplace, typically within 24 hours and nearly real time during low-traffic periods.
Leads: Sent in real time when a lead is created or updated, with capture points including the save-and-exit modal, deeplinks with an email address, SSO entry, and the application flow.
Enrollments (Off-Exchange): Sent in real time on off-exchange application submission, for carriers with off-exchange enabled.
AOR At-Risk: Sent nightly with applications where the submitted NPN may not match the current Agent of Record.
SVI/DMI Followups: Sent in real time as HealthSherpa receives follow-up data from CMS via Event Based Processing or an EDE sync.
A Lead payload with status "enrolled" and an Enrollment payload are both triggered at application submission. They are not sequential, so either may arrive first. Build your processing logic accordingly. |
Payload contents
Enrollment and eligibility payloads share a common structure containing the application, residence, members with demographics and eligibility results (APTC, CSR, SEP), and policies with status, HIOS ID, premiums, and subsidy amounts. Lead payloads include the assigned agent, contact information, household scenario, plan selections, activity timestamps, and attribution data.
HealthSherpa strongly recommends flexible schema validation that tolerates additive changes, so new fields can be introduced without breaking your integration.
HealthSherpa also offers "lite" enrollment postbacks that exclude PHI/PII, useful for teams that need event signals without protected data handling requirements. |
Implementation requirements
To enable postbacks that include PHI/PII, your organization must:
Complete the CMS Privacy and Security audit before postbacks can be enabled in production.
Provide HealthSherpa with your endpoint URL(s) and authentication details.
Build processing on your side to consume the payloads and update your systems.
For postbacks without PHI/PII, the CMS audit step does not apply; you only need to provide your endpoint and authentication method and process what you receive.
Supported authentication
All endpoint URLs must be direct endpoints; HealthSherpa does not follow redirects. Supported webhook authentication schemes include API Key, Basic authentication, Salesforce OAuth (password or JWT), OAuth token, OAuth access token, and Microsoft Client Credentials OAuth. Your TAM can provide the field-by-field requirements for your chosen scheme, along with the outbound IP addresses to allowlist if your endpoint sits behind a firewall.
Visibility and retries
White Label clients also have access to Postback Attempts API endpoints to search recent enrollment postback attempts and retry failed ones. Records are retrievable for 14 days. These endpoints use the same SAML and OAuth2 authentication as HealthSherpa's SSO integration.
Getting started
If you are interested in enabling postbacks or adding payload types, contact your HealthSherpa Technical Account Manager. They will confirm your eligibility, share the full API documentation with payload examples, and coordinate setup and testing in staging before production enablement.