Skip to main content
Some Platform API endpoints are deprecated (scheduled for removal) or sunset (already removed, returning 410 Gone). This page lists each one — its replacement and key dates — and shows how to detect a deprecation from any API response.
Deprecated does not mean gone. A deprecated endpoint keeps working exactly as it does today — same request, same response — right up until its sunset date. Deprecation is advance notice so you can migrate on your own schedule; an endpoint only stops working — returning 410 Gone — once it is sunset.

The endpoint lifecycle

1

Active

The endpoint works normally and sends no deprecation headers.
2

Deprecated

The endpoint still returns its normal 2xx response, now with Deprecation, Sunset, and Link headers. This is your window to migrate — nothing breaks yet.
3

Sunset

On the Sunset date the endpoint stops working and returns 410 Gone. Calls fail until you move to the replacement.
This lifecycle and the deprecation headers apply to all API versions. An endpoint’s sunset date can differ by the version you request — see How sunset dates depend on your version.

How MX signals a deprecation

How MX signals a deprecation depends on what’s being deprecated — a whole endpoint or an individual field.

Endpoint deprecations

Deprecated and sunset endpoints announce their status in every response through standard HTTP headers, so you can detect a pending removal directly from your integration. A deprecated endpoint returns its normal status and body, plus the headers:
Once an endpoint is sunset, it stops doing work and returns 410 Gone:

Field deprecations

Individual request and response fields can also be deprecated. They follow the same lifecycle as endpoints, but they aren’t signaled with the Deprecation and Sunset headers. Instead, the field is marked as deprecated on its endpoint’s page, and the Upgrade Guide explains what replaces it.

Detect a deprecation programmatically

Because the headers ride along on every response, you can watch for them in your existing client and alert before an endpoint ever fails — no need to check this page by hand.

How sunset dates depend on your version

You have until the sunset date shown for your version in the tables below. Which date applies depends on the version you request:
  • On the current version, a short runway (~6 months). The replacement is already available, so a new integration should build against it from the start rather than adopt an endpoint that is already on its way out.
  • On earlier versions, a longer runway (~18 months) to migrate an existing integration. This runway ends on the endpoint’s sunset date or that version’s end-of-life, whichever comes first.
A far sunset date is the migration deadline for that endpoint on that version — not an announced end-of-life for the version itself. Sunset dates are only ever extended, never pulled in without a new announcement.

Deprecated endpoints

These endpoints are still callable and return their normal response today, with deprecation headers. Migrate to the successor before the sunset date that applies to your version. For the request and response changes behind each replacement, see the Upgrade Guide.

Member aggregation endpoints

Paths are relative to /users/{user_guid}/members/{member_guid}/.

Scheduled payments

Paths are relative to /users/{user_guid}/insights/{insight_guid}/.

Legacy endpoints (v20111101 only)

These are already sunset on v20250224 and newer — see Sunset endpoints.

Sunset endpoints

The endpoints that follow return 410 Gone.

Managed data endpoints

These have no direct API replacement — to send data held at your institution to MX, use MDX Real Time until a replacement is added to the Platform API.

Legacy endpoints

On v20111101 these remain deprecated and callable until that version’s end-of-life — see Legacy endpoints (v20111101 only).

Migrating

This page tells you what is deprecated and when it sunsets. For the how — the exact request and response changes for each replacement — see the Upgrade Guide.