Overview

Each year, Spark analyzes your book of business to flag clients affected by major plan changes heading into the new year: plan exits, crosswalks, provider network changes, and prescription disruptions. This analysis powers your in-platform work queues, and it can also be pushed automatically to a supported third-party CRM using Spark Webhooks.

This article explains three things:

what the plan disruption analysis is
why webhooks are relevant and how to set them up
how disruptions are represented in the webhook payload.

Each section links to a dedicated guide for more detail.

What is the plan disruption analysis?

Every year, Medicare Advantage and Part D plans update their provider networks, drug formularies, and benefits. These updates are required by CMS and take effect January 1 of the following year. As a result, a client's prescription may cost more or drop off the formulary, a supplemental benefit may be reduced, or an entire plan may exit the market.

Spark's disruption analysis reviews each client's active coverage against these upcoming changes and flags the specific disruption(s) affecting them. In the Spark platform, flagged clients surface in your Contact List under the Action Items tab when they need agent action, and under the Activity tab as informational FYIs. Spark prioritizes each contact by severity, and the items shown adjust by season (for example, AEP vs. OEP).

For a full breakdown of each disruption type including how the beneficiary is affected, how you can help, and ready-to-use outreach templates and talk tracks see:

Why webhooks are relevant

The disruption analysis is most valuable when it drives outreach. If your agency runs its outreach, automations, or reporting in a third-party CRM rather than (or in addition to) Spark, a webhook lets Spark push each contact along with any disruptions Spark has identified, directly into that system in near real time. That means the same disruption signals you see in your Spark work queues can trigger automated campaigns, tasks, or alerts in your CRM without any manual export.

Spark Webhooks perform a unidirectional sync: contact and policy data flows from Spark out to your platform of choice. Triggers typically fire within a few seconds (occasionally a few minutes), so whenever a contact or their policies are updated in Spark, the change propagates to your CRM.

Note: The webhook only pushes out contacts with an active or pending policy.

For full setup instructions, including a step-by-step GoHighLevel (GHL) walkthrough and field-mapping guidance, see the Contact Sync (Webhook Guide).

Setting up a webhook (quick version)

In the Spark platform, go to Back Office → Manage platform data.
In the Webhook section, click Add Webhook URL and paste your endpoint URL.
Click Test URL to send a test payload and confirm the connection. A Verified badge appears once the test succeeds.
In your CRM, use the test/sample payload to map Spark's fields to your platform's fields.

A few important requirements:

Your CRM must support incoming webhooks natively. If it doesn't, you'll need an integration layer that can receive the webhook and pass the data into your CRM through a supported method.
Zapier cannot be used for this integration, as it is not HIPAA compliant.
If you use GoHighLevel, enable and maintain GHL's additional HIPAA encryption feature, since HighLevel accounts are not HIPAA compliant by default.

What the webhook communicates

When Spark fires a webhook, it sends a JSON payload describing the contact, their agent, and their policies, including any disruptions. At a high level the payload contains:

Section	Contents
`unique_id`	A unique identifier for the event
`metadata.event_type`	The event that triggered the webhook (e.g., `CONTACT_CREATED`)
`timestamp`	When the event occurred
`details`	Contact-level information: name(s), phone, email, addresses, point of contact, assigned agent, SOA status, preferred language, and more
`phi`	Protected health information: date of birth, MBI, Medicaid/LIS status, Part A/B enrollment dates, and the `policies` object

Where disruptions live in the payload

Disruptions are represented inside phi.policies. Alongside the standard active and pending policy categories, the analysis populates a dedicated category for each disruption type. When Spark identifies a disruption for a contact, the affected policy appears under the matching category:

Payload category	What it means
`plan_exits`	The client's current plan will not be offered next year. Coverage ends December 31; without action they typically revert to Original Medicare.
`plan_crosswalk`	The plan is discontinued, but the carrier automatically enrolls the client into another plan in its portfolio for the new year.
`prescription_removed_from_formulary`	A medication the client currently takes has been removed from the plan's formulary for the new year.
`drug_tier_change`	One of the client's prescriptions has moved to a higher formulary tier, increasing their copay or coinsurance.
`major_cost_change`	A significant cost change to the client's coverage (for example, a prescription price increase even when the drug remains covered).

Each of these categories mirrors a disruption scenario documented in the Plan Disruption Comms and Talking Points guide, so you can pair the data your CRM receives with the corresponding outreach template.

Putting it all together

The full workflow looks like this:

Analysis — Spark reviews each client's coverage against upcoming CMS-required plan changes and flags disruptions.
In-platform — Flagged clients appear in your Contact List Action Items and Activity queues, prioritized by severity.
Webhook — For contacts with an active or pending policy, Spark pushes the contact and their disruption categories to your connected CRM in near real time.
Outreach — Your CRM uses those disruption signals to trigger automated campaigns or tasks, which you can pair with Spark's talking points and outreach templates.

Related resources

Contact Sync (Webhook Guide) — Full webhook setup, GoHighLevel walkthrough, field mapping, and the complete payload.
Contact List Work Queues — How flagged disruptions surface as Action Items and Activity inside Spark.
Plan Disruption Comms and Talking Points — What each disruption type means and how to communicate it, with outreach templates.

Plan Disruption Analysis & Webhooks