--- title: "Entitlement Management on Cloud Marketplaces" url: https://www.suger.io/resources/blog/marketplace-entitlement-management/ canonical: https://www.suger.io/resources/blog/marketplace-entitlement-management/ type: Blog description: "How marketplace entitlement management works: the purchase-to-access path on AWS, Microsoft and Google Cloud, and the design rules that keep it correct." --- # Entitlement Management on Cloud Marketplaces > Canonical HTML version: https://www.suger.io/resources/blog/marketplace-entitlement-management/ 1. [Home](/) 2. / 3. [Resources](/resources/) 4. / 5. [Blog](/resources/blog/) 6. / 7. Entitlement Management on Cloud Marketplaces # Entitlement Management on Cloud Marketplaces A purchase event is not an entitlement, and an entitlement is not access. The three-hop path between them is where marketplace products quietly break. [![Chloe Wu](/authors/chloe-wu.jpg)](/resources/blog/author/chloe-wu/) [Chloe Wu](/resources/blog/author/chloe-wu/) Aug 12, 2026 ![Entitlement Management on Cloud Marketplaces](/images/blog/marketplace-entitlement-management/hero.png) Explore AI Summary [![](/logos/company/openai.svg)](https://chat.openai.com/?q=Read%20and%20summarize%20https%3A%2F%2Fwww.suger.io%2Fresources%2Fblog%2Fmarketplace-entitlement-management%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Cloud%20GTM%2C%20Marketplaces. "Summarize with ChatGPT")[![](/logos/company/anthropic.svg) ](https://claude.ai/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.suger.io%2Fresources%2Fblog%2Fmarketplace-entitlement-management%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Cloud%20GTM%2C%20Marketplaces. "Summarize with Claude")[![](/logos/company/gemini.svg)](https://www.google.com/search?udm=50&aep=11&q=Read%20and%20summarize%20https%3A%2F%2Fwww.suger.io%2Fresources%2Fblog%2Fmarketplace-entitlement-management%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Cloud%20GTM%2C%20Marketplaces. "Summarize with Gemini")[](https://www.perplexity.ai/search/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.suger.io%2Fresources%2Fblog%2Fmarketplace-entitlement-management%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Cloud%20GTM%2C%20Marketplaces. "Summarize with Perplexity") Table of Contents - [What is entitlement management?](#what-is-entitlement-management) - [The three hops, and where they break](#the-three-hops-and-where-they-break) - [How each cloud implements it](#how-each-cloud-implements-it) - [Design rules that survive contact with production](#design-rules-that-survive-contact-with-production) - [Frequently asked questions](#frequently-asked-questions) - [Takeaways](#takeaways) _Entitlement management is the work of turning a marketplace purchase into product access that is correct, current, and revocable. It is three hops — event, entitlement, access — and each cloud implements them differently. Getting it right is unglamorous. Getting it wrong produces customers who paid and can’t log in, and customers who cancelled and still can._ * * * Every marketplace integration starts the same way: a webhook arrives, the engineer wires it to a “create user” function, and it works. It keeps working for months, because most purchases are simple and most customers do not immediately change anything. Then a customer upgrades mid-term, a payment fails after the landing page redirect, an agreement is replaced rather than renewed, and the model that treated events as instructions produces access that nobody can explain. Here is the shape that holds up, and what each cloud actually gives you to build it from. * * * ## **What is entitlement management?** **Entitlement management is maintaining, for every buyer, an accurate answer to “what are they entitled to right now,” and making your product enforce it.** It is distinct from the two things it sits between: the commercial record of what was sold, and the user accounts in your product. The distinction that matters most operationally is between an **event** and **state**: - An **event** is a notification that something changed. It arrives once, may arrive twice, may arrive out of order, and describes a moment. - **State** is what the buyer is entitled to now. It is authoritative, it lives with the marketplace, and you read it on demand. **Build on state; use events only as a prompt to re-read it.** Every durable marketplace integration converges on this, and every fragile one is an event handler that mutates local records directly. If the offer/entitlement vocabulary is new, [offer vs entitlement](/resources/blog/offer-vs-entitlement/) covers the two record types before this post’s mechanics. * * * ## **The three hops, and where they break** Hop What happens Failure mode Purchase → event The marketplace notifies you Missed, duplicated, or out of order Event → entitlement You read the authoritative state Trusting the event payload instead Entitlement → access Your product grants or revokes Access granted before payment confirms The middle hop is the one teams skip, and AWS makes the reason to keep it explicit. Its entitlement topic sends the same action value for every kind of change: “regardless of the action (new, upgrade, renewal, or expired), the message is the same,” and “a subsequent call to `GetEntitlement` is required to discover the content of the update.” That is a design instruction disguised as a note. You are not being told what changed — you are being told to go and look. * * * ## **How each cloud implements it** ### AWS Two SNS topics carry the signals for SaaS products. **`aws-mp-subscription-notification`** covers the subscription lifecycle with four action values: - `subscribe-success` — the point at which “the seller can begin sending metering records.” If an agreement-based offer is later accepted, the message is sent again with the new offer identifier. - `subscribe-fail` — payment may have failed even though the buyer already reached your landing page. AWS is direct about the implication: “The seller should wait for the `subscribe-success` message before allowing consumption of the product.” - `unsubscribe-pending` — the buyer has cancelled, and you have “a limited time (about one hour) to get final metering records sent before the buyer is cancelled completely.” - `unsubscribe-success` — cancellation is complete, and no further metering records will be accepted. **`aws-mp-entitlement-notification`** covers contract products and, as above, always sends `entitlement-updated`. Two subtleties worth designing for. If a buyer unsubscribes and immediately re-subscribes before the final message is sent, “the final `unsubscribe-success` message will not be sent and a `subscribe-success` message will be sent instead” — so a state machine that requires the cancellation to complete before a new subscription can start will deadlock. And for future dated agreements, the notifications fire on the **agreement start date, not the sign date**. AWS recommends subscribing an SQS queue to the topics and polling it, which also gives you the durability and retry behaviour an HTTP endpoint does not. Note the account constraint: you can only subscribe to the topics from the AWS account used to sell the products, though messages can be forwarded elsewhere. One forward-looking item: AWS states that “SNS notifications for AWS Marketplace SaaS products are being replaced with Amazon EventBridge notifications,” with existing SNS integrations continuing to function. A new build should target EventBridge. ### Microsoft Microsoft’s flow is a redirect rather than a pure event stream. The buyer lands on your **landing page** carrying a marketplace purchase identification token, which you exchange for subscription details using the **resolve** API, then complete onboarding and call **activate** to start the subscription period. Asynchronous changes arrive at your **connection webhook** — Microsoft describes it as “the only way you get notified about updates to your customers’ SaaS subscriptions.” Both the landing page and the webhook “should be running 24/7.” One behaviour that changes the shape of your code: if auto-activation is enabled on a plan, “the subscription activates and billing starts immediately at purchase. You don’t need to call the Resolve or Activate APIs for auto-activated plans. Instead, you receive a `Subscribe` webhook notification with the subscription details.” A single implementation therefore has to handle both an interactive path and a silent one. ### Google Cloud Google Cloud Marketplace splits the job across three service accounts: the **Partner Procurement API** for purchase information and entitlement management, **Pub/Sub** for notifications, and the **Service Control API** for reporting usage on consumption-priced products. Google’s own framing is that the integration lets you “manage users’ accounts and entitlements, which indicate that users have bought your product from Cloud Marketplace.” * * * ## **Design rules that survive contact with production** **Make handlers idempotent.** The same message will arrive twice. Processing it twice must produce the same result as processing it once. This is cheap to build in and expensive to retrofit. **Reconcile on a schedule, not only on events.** A nightly pass that reads every entitlement and compares it to the access you have granted catches the missed message, the handler that threw, and the manual change somebody made in a console. Teams that add this find drift in the first run — that is the point. **Never provision on the offer.** Wait for the confirmation event. On AWS that is explicitly `subscribe-success`. Granting access at the landing page means supporting customers whose payment later failed. [When a buyer pays but provisioning never happens](/resources/blog/marketplace-provisioning-failures/) covers the whole failure surface. **Revoke as carefully as you grant.** Most products have a well-tested grant path and a revoke path nobody has run. Expiry, cancellation and non-renewal all end an entitlement, and if nothing reacts you are giving software away in a way no report will show. **Keep an audit trail keyed to the marketplace identifier.** When finance asks why a customer had access in March, the answer needs to be a record, not a reconstruction. **Design for the one-hour window.** On AWS, `unsubscribe-pending` starts a clock for final metering. If your metering pipeline batches hourly, you can miss the last records of every cancellation — which is revenue you earned and did not bill. * * * ## **Frequently asked questions** **What is entitlement management on a cloud marketplace?** Maintaining an accurate, current answer to what each buyer is entitled to, and enforcing it in your product. It sits between the commercial record of the sale and the user accounts in your system. **Should I trust the event payload or call the API?** Call the API. AWS’s entitlement topic sends the same action for new contracts, upgrades, renewals and expiry, and states that a `GetEntitlement` call is required to discover what changed. **When can I start metering an AWS Marketplace customer?** On `subscribe-success`. AWS states that this message signals when the seller can begin sending metering records, and that you should wait for it before allowing consumption. **What happens when an AWS buyer cancels?** You receive `unsubscribe-pending` first, giving about one hour to send final metering records, then `unsubscribe-success`, after which no further metering records are accepted. **Do I need the resolve and activate APIs on Microsoft?** Not for auto-activated plans. Microsoft states that with auto activation the subscription activates and billing starts at purchase, and you receive a Subscribe webhook notification instead. **Why reconcile entitlements if I handle every event?** Because messages get missed, handlers fail, and consoles get edited by people. A scheduled reconciliation against authoritative state is the only thing that catches drift you did not cause. * * * ## **Takeaways** - Events are prompts; entitlements are state. Read the authoritative record rather than acting on the payload. - AWS sends one action value for every entitlement change and requires a `GetEntitlement` call to learn what it was. - Wait for `subscribe-success` before granting access or metering. A landing page redirect is not a confirmed payment. - `unsubscribe-pending` opens a window of about one hour for final metering records. Batch pipelines miss it. - Microsoft’s auto-activated plans skip resolve and activate entirely and arrive as a Subscribe webhook, so one implementation must handle two paths. - Reconcile entitlements on a schedule. The first run always finds drift, which is the argument for having it. * * * Three clouds, three event models, one question your product has to answer correctly every time. See how Suger’s [agreement and entitlement management](/platform/agreements/) keeps entitlement state consistent across every marketplace, so your product reads one source instead of three. ## Sources Primary sources for the platform rules cited above. Last verified August 12, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure. - [AWS Marketplace Seller Guide: Amazon SNS notifications for SaaS products](https://docs.aws.amazon.com/marketplace/latest/userguide/saas-notification.html) — Both SNS topics, every action value, the one-hour unsubscribe window, the GetEntitlement requirement, and the EventBridge replacement notice - [Microsoft Learn: Plan a SaaS offer for Microsoft Marketplace](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/plan-saas-offer) — The resolve and activate flow, the landing page and webhook requirements, and auto-activation behaviour - [Google Cloud Marketplace: Backend integration for SaaS products](https://docs.cloud.google.com/marketplace/docs/partners/integrated-saas/backend-integration) — The Partner Procurement API, Pub/Sub notifications, and the Service Control API for usage reporting ### Stay Updated Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.