Adobe is retiring the Analytics 1.4 API on 12 August 2026. Every endpoint under api*.omniture.com stops responding that day — not a slow deprecation with a warning banner, a hard cutover. Any integration still calling 1.4 goes dark instantly: scheduled data exports, BI dashboards, warehouse pipelines, marketing mix models, and third-party connectors built years ago by someone who has since left the team. The problem most organisations have isn’t unwillingness to migrate, it’s not knowing how many things still depend on the old API until one of them breaks in production.
The migration itself is more than a URL swap. Analytics 1.4 uses WSSE authentication with a username and shared secret; Analytics 2.0 requires OAuth credentials issued through the Adobe Developer Console. Report suite identifiers, response schemas, and some calculated-metric definitions differ between the two versions, so a lift-and-shift rarely works cleanly — teams that migrate the auth layer without validating that the new responses actually match the old ones tend to discover silent data discrepancies weeks later, usually when a stakeholder asks why a familiar number changed.
Data Points to Track
- 1.4 endpoint call volume by consumer — which internal tools, scheduled exports, or third-party connectors are still hitting the legacy
api*.omniture.comdomain, broken down by system rather than aggregated - WSSE credential usage — which service accounts or shared secrets are still authenticating via WSSE instead of OAuth, so nothing gets missed when credentials are rotated out
- Migration status per integration — not started, in progress, or verified in production, tracked against the 12 August deadline rather than left as a single project-wide status
- Report suite ID mapping accuracy — confirmation that every 1.4 suite ID resolves to the correct 2.0 equivalent, since a wrong mapping returns plausible-looking but incorrect data rather than an error
- Data parity between 1.4 and 2.0 responses — side-by-side comparison of core metrics (visits, revenue, conversion events) for the same date range, run before any integration is cut over
Setup Steps
- Audit every system calling the Analytics API for requests to
api*.omniture.com, using API gateway or proxy logs if you have them, since manual memory of “what calls Adobe” is rarely complete. - Inventory WSSE-authenticated service accounts and register equivalent OAuth server-to-server credentials for each one in the Adobe Developer Console before touching any integration code.
- Migrate the lowest-risk integration first — an internal dashboard rather than a revenue-reporting pipeline — to surface schema or authentication issues somewhere recoverable.
- Run 1.4-versus-2.0 parity checks for at least two weeks on overlapping date ranges before retiring the old call in any integration you consider business-critical.
- Set an internal deadline well ahead of 12 August, with a named owner for each remaining integration and a rollback plan for anything that isn’t verified in time.
Actionable Insights
The 1.4 endpoint call volume metric is the one to build the whole migration plan around — it tells you exactly what will break and in what order of priority, rather than relying on a best-guess list of “known” integrations. Parity failures are almost always more informative than outright errors: a 2.0 response that returns data but with a different revenue figure or session count than 1.4 usually points to a report suite mapping issue or a calculated metric that was redefined between versions, and catching that before cutover is far cheaper than reconciling it against a finance team’s numbers afterwards. Treat 12 August as a hard deadline, not a target — anything still calling 1.4 that day simply stops.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert