Google Workspace Marketplace Licensing API: Why licenseNotification Is Dead and What Replaces It
Most Marketplace app integrations still call licenseNotification.list to track installs. Google deprecated it in January 2026 — with no replacement method. If your app's provisioning logic depends on that endpoint, it will keep returning data until Google shuts it off, then stop silently. Here is what the Marketplace API's licensing endpoints actually return, the single OAuth scope behind them, and the distinction between enabled and state that decides whether a user can actually open your app.
Deprecated, January 8, 2026: the licenseNotification resource and licenseNotification.list method are gone from the Google Workspace Marketplace API reference. Google's own release note says there is no alternative resource or method within the API — install and delete events now have to come from Google Analytics event tracking instead, a completely different data pipeline than a REST poll.
What the Licensing API Still Does
Two methods remain live on appsmarket.googleapis.com, and they answer two different questions.
userLicense.get
GET /appsmarket/v2/userLicense/{applicationId}/{userId}
- Answers: can this one person open the app right now?
- Returns
enabled(has a domain admin turned the app on for this user's org/OU) andstate(does this specific user hold a valid license —ACTIVEorUNLICENSED) - These two fields move independently — see the risk section below
customerLicense.get
GET /appsmarket/v2/customerLicense/{applicationId}/{customerId}
- Answers: does this domain, as a whole, have any relationship with the app?
- Returns
stateonly —ACTIVEif the domain has ever installed and not fully removed it,UNLICENSEDif never installed or fully deleted - The
editions[]array (editionId, seatCount, assignedSeats) is itself marked deprecated in the current schema — present in responses, not reliable for seat-count logic
The Single Scope Behind Both Calls
Both methods run under one OAuth 2.0 scope: https://www.googleapis.com/auth/appsmarketplace.license — Google's own description is “view your installed application's licensing information.” There is no separate read/write split and no per-method scope. Get this scope wrong in your consent configuration and both endpoints return an auth failure, not a partial result.
How a Licensing Check Actually Gets Built
Confirm the app is Marketplace-enabled, not just OAuth-verified
The Marketplace SDK configuration and the OAuth consent screen are separate settings inside the same Cloud project. A verified OAuth app with the SDK not configured cannot serve licensing calls.
Request the appsmarketplace.license scope explicitly
It is not bundled into any broader Workspace scope — it has to be requested on its own during the OAuth flow that authorizes your server to call the Marketplace API.
Call userLicense.get per user, not per domain
A domain-level customerLicense.get check does not tell you whether an individual signed-in user currently has access — admin-scoped installs, OU-scoped installs, and individually self-installed licenses all resolve differently at the user level.
Read enabled and state as two separate gates, not one flag
Both have to evaluate the way your access logic expects, or a technically “licensed” user can still be blocked, or vice versa. Detail below.
Replace any licenseNotification-based install tracking
Since there is no direct API substitute, install/removal event tracking now has to move to the GA4-based Marketplace SDK analytics events instead of a licensing poll.
What the Response Actually Confirms
Where This Trips Up Real Integrations
enabled and state answer different questions — and can disagree
Google's own documented example: after a domain admin restricts the app to a single organizational unit, a user outside that OU can still show state: ACTIVE (they hold a valid license) while enabled: false (the admin has not turned the app on for their part of the org). Gate access on the wrong field alone and you either lock out a licensed user or let in someone the admin scoped out.
Deletion at the domain level does not always mean deletion for the user
If a user individually installed the app before an admin-wide install ever existed, removing the app for the whole organization does not remove that individual's own license — their userLicense.get call can still return enabled: true, state: ACTIVE after the org-wide removal.
The editions array is not a safe seat-count source going forward
editionId, seatCount, and assignedSeats inside customerLicense are all individually flagged deprecated in the current schema. Any billing or seat-limit logic still reading those fields is built on a field Google has already marked for removal, with no successor field named in the reference.
licenseNotification cannot be swapped for a direct API replacement
Google's release note is explicit that no alternative resource or method exists inside the Marketplace API itself. Any install/delete event pipeline built on that endpoint needs a different data source, not a like-for-like API substitution.
Getting a Marketplace listing to this point — OAuth consent screen configured, Marketplace SDK enabled, the correct scope requested and verified, and licensing calls returning the fields your access logic actually needs — is exactly where I help SaaS teams that are stuck between a working OAuth app and a working Marketplace listing. See how this fits with the OAuth verification work in Google OAuth Verification: How to Pass the Sensitive & Restricted Scope Review, or with the broader Workspace API approval path in Google Workspace API Verification: Why the Approval Path Is Different. If your integration also touches the YouTube Data API, YouTube API Key vs OAuth 2.0 covers the related verification trigger.
Sourced from Google's official Workspace Marketplace API reference (developers.google.com/workspace/marketplace) — the Get app installation and licensing details guide, the customerLicense and userLicense REST resources, the Marketplace API scopes page, and the Marketplace release notes, all current as of 2026-08-05. No install volume, approval rate, or timeline figures are claimed anywhere in this article because Google does not publish them for this API.