pixellint

Blog · LiveRamp ATS

LiveRamp ATS Mobile SDK sunsets September 30, 2026. The envelope moves to the ATS API.

· 10 min read

The ATS Mobile SDK is deprecated and fully sunsets September 30, 2026. In-app authenticated traffic that still calls the SDK after that date will not mint RampID envelopes. Web ATS and the API remain. This is not a new identity product.

LiveRamp posted the deprecation notice on 29 May 2026. The instruction is to finish the ATS API implementation before the sunset date. Today is 8 September 2026. That is 22 days. The SDK page in Console still explains Config IDs, envelope refresh, and fake envelopes on unapproved placements. Those screens do not extend the sunset.

ATS still turns a consented identifier into an encrypted envelope that carries a RampID. Depending on the integration, that envelope may also carry PAIR IDs and Facebook-scoped envelopes. The product on the web does not move. The in-app client that retrieved, refreshed, and cached those envelopes does. Teams that treat this as a new graph, or as a UID2 recap, will miss the hop that actually dies on 30 September.

What sunsets, and what does not

ATS for publishers has three implementation paths in the getting-started guide. ATS for Web is a JavaScript snippet from Console on the page header. ATS API is a direct envelope call, including server-to-server, if you want less JavaScript. ATS Mobile SDK is Android and iOS: retrieve, refresh, cache, consent handling. The same page now labels the SDK deprecated and points mobile publishers at the ATS API implementation guide on the developer portal.

The Connect ATS overview repeats the sunset in a notice: the Mobile SDK is deprecated and will be fully sunset on September 30, 2026. You continue mobile identity by transitioning to ATS API. Web JavaScript is not in that sentence. Direct API is not in that sentence. ESP integrations that send identifiers into ATS are not in that sentence. The SDK that minted in-app envelopes without you writing the envelope call is the thing that goes away.

If the app still calls the SDK after 30 September, LiveRamp's own interruption warning applies. The deprecation page says you must transition and have the API fully implemented before that date to avoid interruptions with your mobile identity integration. I am not going to invent a remaining-traffic percentage. The vendor sentence is the cutoff. After that date, authenticated in-app traffic on the SDK path is not a RampID source.

The envelope is still a RampID envelope

ATS resolves consented user data to a RampID in real time so authenticated, cookieless inventory can carry a people-based id in the bidstream. The flow on the overview page is: the user authenticates, ATS builds an encrypted identity envelope containing RampID, the SSP decrypts with Sidecar and puts RampID on the bid request, the DSP bids. That is web-shaped language. The identifier in the envelope is still RampID. Moving mobile from SDK to API does not mint a different people id.

RampID is LiveRamp's pseudonymous identifier in the LiveRamp Identity Graph. The overview describes hashing, salting, and private key encryption so consumer data is not re-identified from the id. Envelopes may also contain PAIR IDs, Facebook-scoped envelopes, and other identifiers used to send conversion events for marketer use cases. Those are enablements on the ATS configuration, not a reason to keep the SDK.

UID2 interoperable IDs are a separate enablement. Unified ID's LiveRamp tips say you must turn on Interoperable IDs and have UID2 appended, or UID2 tokens will not ride in the ATS envelope. That is Console work with a LiveRamp representative. It is not this sunset, and it is not a recap of the January UID2 post. If you needed UID2 in the envelope last winter, you still need that flag. If you only needed RampID in-app, the job this month is the API cutover.

The SDK was a client with a Config ID

The implement guide still documents the old client because people have to migrate off it. You need an approved ATS placement. You subscribe to the ATS Mobile SDK product. In Console, ATS then Mobile, you create a configuration, pick a placement, and get a Config ID. LiveRamp recommends a separate Config ID per iOS or Android title so reporting stays split. Channel partners can permission each configuration.

Unapproved placements return fake envelopes until approval. That is a test footgun that will look like a successful migration if you point the new API at a placement that was never approved, or if you keep a debug Config ID in production. Envelope expiration defaults to 15 days. Minimum refresh interval defaults to 15 minutes. Logging can dump all levels to Xcode or Logcat in development; production logs errors and warnings. None of those knobs are a sunset extension.

ATS On-Device is an optional integration key on that same Mobile configuration. It exists to handle identifiers from users who opted out of App Tracking Transparency on iOS. That is still SDK-era Console. ATT opt-out traffic does not keep the SDK alive past 30 September. If you needed On-Device because IDFA was gone, the replacement path LiveRamp names is still the ATS API, not a new ATT product.

The path that dies on 30 September

An in-app client still initialized with a Mobile SDK Config ID. After 30 September 2026 this is not a RampID minting path.

{
  "identity_path": "ats_mobile_sdk",
  "config_id": "xxxxxxxx",
  "placement": "approved",
  "envelope_refresh_minutes": 15,
  "sunset": "2026-09-30",
  "replacement": "ats_api"
}

That object is the configuration a lot of apps still ship: Config ID from Console, placement approved, refresh at the default interval. It is not an envelope. After sunset it is a call into a retired client. The replacement LiveRamp names is the ATS API, including the mobile publishers guide on the developer portal. I am not going to invent that API's path or field list here. The deprecation notice is the market event. The field list belongs in the API guide LiveRamp pointed you at in May.

Web ATS stays a snippet. Direct API stays a direct call for people who already wanted less JavaScript, now including the in-app authenticated traffic that used to sit in the SDK. Prebid, PAIR, Google Secure Signals, and ESP feeds are other ATS surfaces. They are not a reason the SDK keeps working.

Names that do not translate

Twenty-two days is an implementation calendar

May 29 was the notice. September 30 is the sunset. September 8 is late to discover you still initialize the SDK in the iOS and Android apps that carry authenticated users. The work is not a new identity vendor. It is swapping the minting client for the API LiveRamp already offered to publishers who did not want the JavaScript, and documenting that the in-app identifier you send is still consented, and that the envelope you cache still expires.

If your in-app conversions also POST to an MMP S2S hop, that is a different envelope on a different host. An AppsFlyer S2S event does not mint a RampID. A RampID envelope does not replace appsflyer_id. ATT status still belongs on the MMP payload where that vendor asks for it. Do not merge those jobs because both say mobile identity.

Publishers who only run ATS on the website are not the audience for this cutoff, except as a reminder that the Mobile row in Console is not harmless leftover config. If an app build still ships the SDK, that build is on the clock. If you already call the ATS API from the app backend, confirm it with LiveRamp's mobile publishers guide, then ignore the SDK screens.

LiveRamp has made the decision to deprecate the ATS Mobile SDK, with a targeted sunset date of September 30, 2026. To continue leveraging LiveRamp's mobile identity capabilities, users should make the transition to the ATS API before the sunset date.

LiveRamp deprecation notice (29 May 2026)

What to do

Inventory every iOS and Android title that still initializes ATS Mobile SDK. For each Config ID, map the placement, the envelope refresh, and whether production still depends on SDK-minted envelopes. Implement the ATS API for those titles before 30 September 2026. Keep Web ATS. Do not treat UID2 interoperable IDs as the migration.

Confirm placements are approved so you are not minting fake envelopes. Keep consent on the identifier you send. Cache and refresh on the intervals LiveRamp documents for the API path, not on a Config ID that will not be a client. If ATT opt-out traffic mattered, ask LiveRamp how that traffic moves on the API. Do not assume On-Device keys survive the SDK.

The contract page for identity graphs is the docs. This post is the market fact: the in-app ATS client has a date, and the envelope is still RampID. Pixellint is not affiliated with LiveRamp. Passing a linter means the artifact matches a published envelope. It does not mean a DSP resolved the person, and it does not detect fraud.

Checklist

Sources

Contract pages

The dated argument is above. These pages are the field lists.

Read identity graphs Docs