Two Marketo deprecations land within a month of each other, and if your integration is still running either one, the reason is almost certainly the same: both dates have moved before, and moving deadlines train teams to wait.

Here is the history, because it explains the current state of most Marketo integrations better than any technical detail does. Adobe originally announced both the SOAP API retirement and the removal of access_token query-parameter authentication for 31 October 2025. That was pushed: “Previously, both the SOAP API, and the REST API Access Token in Query Parameter were to be deprecated on 31 October 2025. They will now be deprecated on 31 January 2026.” Then it moved again, into mid-2026.

A deadline that slips twice gets treated as a deadline that will slip a third time. This one appears not to have.

The dates, and a discrepancy worth knowing about

Adobe’s developer documentation states the SOAP API is deprecated and will no longer be available after 31 July 2026 — a date now behind us — with all new development on the REST API and existing services migrated to avoid service interruption.

For query-parameter authentication, the current Marketo Engage release notes list the deprecation with a deadline of 31 August 2026: the access_token query parameter is being phased out and all integrations, new and existing, must move to the Authorization header.

Note the inconsistency. Some Adobe developer pages give 31 July 2026 for both items, while the current release notes carry 31 August for the query parameter specifically. Do not plan against the later date. If two Adobe surfaces disagree, the safe reading is the earlier one, and in this case the earlier one has already passed.

What actually breaks

SOAP. Everything. There is no graceful degradation for a retired endpoint — calls fail, and any middleware still issuing them fails with them. The exposure is rarely the code someone is actively maintaining; it is the integration built years ago by a contractor, still running on a schedule, still moving leads, and not in anyone’s mental model of the stack. Legacy getLead, syncLead, and list-membership calls are the usual survivors.

Query-parameter auth. This one is nastier precisely because it is a one-line problem. Authentication stops working, so every call fails at once, and the failure mode looks like an outage rather than a deprecation. Anything appending ?access_token= to a REST call is affected: shell scripts, Postman collections checked into a repo, iPaaS connectors configured through a UI, and — commonly — a monitoring job somebody wrote in an afternoon three years ago.

The auth migration itself

The change is genuinely small. Stop putting the token in the query string; put it in the header.

# Before
GET /rest/v1/leads.json?access_token=<token>&filterType=id&filterValues=1

# After
GET /rest/v1/leads.json?filterType=id&filterValues=1
Authorization: Bearer <token>

The token acquisition flow does not change. Only its transport does.

The work is not the edit — it is finding every call site. A few approaches that surface more than a code search alone:

  • Grep for access_token= across every repo, not just the ones that look like integration code. Include .http, .json Postman exports, CI configs, and any curl in a runbook or wiki.
  • Search your own logs and any API gateway in front of Marketo for request URLs containing the parameter. This catches callers you do not have the source for, which is the population that matters.
  • Check iPaaS and low-code tools by hand. Workato, Zapier-style connectors, and in-house Retool panels store auth config outside version control, so the code search will never see them.

There is also a security argument for having done this years ago: tokens in query strings land in access logs, proxy logs, browser history, and Referer headers. The header was always the correct place.

Two adjacent limits landing right behind these

While auditing, note two other changes in the current release notes that will produce failures in the same code paths:

  • Static list size limit, effective 30 September 2026. API calls targeting lists with 10,000 or more leads will fail with error code 1003. Any nightly job that pulls membership of a large list needs to be rebuilt around pagination or a different retrieval strategy before then.
  • Merge Leads limit. A maximum of 25 IDs per merge request; larger operations must be split across multiple calls.

There is also a formatting correction to Campaign Run ID values, which previously came back wrapped in double quotation marks and will now return as proper numbers. Harmless unless something downstream parses that field as a string and compares it literally — in which case it is a silent data bug rather than an error, which is worse.

A migration order that reflects the actual risk

Do the auth change first, everywhere, regardless of what else is pending. It is mechanical, it is testable in isolation, and it is the one with a hard date still ahead of you.

Then inventory SOAP usage by looking at traffic rather than code. Marketo admin surfaces which API users exist; correlate that against what your team believes it runs, and treat every unexplained caller as a live SOAP integration until proven otherwise. The integrations nobody remembers are exactly the ones that were never migrated.

Then handle the list-size limit before the end of September, because a job that fails with error 1003 at 2 a.m. on 1 October will be diagnosed as a Marketo outage by whoever is on call.

The pattern across all of this is unremarkable and worth stating anyway: the risk in a deprecation is almost never the endpoint you know about.