The AWS Marketplace API, Explained: How ISVs Automate Listing and Selling

Aein Eskandari Founder, Automatum

Most sellers meet AWS Marketplace through the Management Portal: a web console for creating a listing, sending a private offer, and pulling a report. For one product, that is enough. It stops scaling the moment you are running dozens of private offers a quarter, carrying multiple products, or trying to make your listing move through the same release pipeline as your code. Underneath that console sits a set of public APIs that do most of what the console does — and a few things it can’t. This is the map, and the order to build in.

The console is a floor, not a ceiling

Here is the fact that reframes everything: per AWS, the Catalog API is what provides the self-service publishing capabilities inside the AWS Marketplace Management Portal (AMMP). When you edit a product in the console, you are using a client of the same API you can call directly (AWS Marketplace Catalog API docs, 2026). The console is not the product and the API a bolt-on — it is the other way around.

That matters because the console’s limits are human limits, not platform limits. Anything you do by hand — updating a description, cloning an offer, reconciling a report — is a candidate for automation, and AWS explicitly supports integrating the Catalog API with your product build or deployment pipelines to automate product updates (AWS Marketplace Catalog API docs, 2026).

The AWS Marketplace API is a family, not a single endpoint

Search for “AWS Marketplace API” and it is easy to assume one interface. In reality AWS ships several distinct services, each scoped to a stage of the seller lifecycle. Per the AWS Marketplace API Reference (2026), these are the ones ISVs actually build against:

Which API does which job

The fastest way to orient is to start from the task you are trying to automate and work back to the service. This table is the cheat sheet.

That last row is newer and easy to miss. In November 2024, AWS launched the Partner Central API for Selling with AWS, which lets partners create, update, and assign ACE co-sell opportunities and associate Marketplace offers directly from their CRM (AWS What’s New, 2024). A year later, in November 2025, AWS brought Partner Central into the AWS Management Console, unifying it with the Management Portal under IAM permissions and expanding the co-sell and Marketplace APIs (AWS What’s New, 2025). The programmatic surface is widening, not narrowing.

Automating the listing itself: how the Catalog API thinks

The Catalog API has a specific mental model, and fighting it is the usual source of pain. Every change specifies the entity to change, the type of change (a ChangeType), and its details; a collection of change types is a ChangeSet submitted with StartChangeSet (AWS Marketplace Catalog API docs, 2026). Two properties of that model shape everything you build.

First, it is batch-and-chain. You can combine and chain up to 20 changes in one StartChangeSet request targeting one or multiple entities — the canonical example being to create a SaaSProduct draft, create its Offer draft, and fill in both sets of metadata in a single change set, referencing the new product later in the same set (AWS Marketplace Catalog API docs, 2026). A new listing is one atomic operation, not a sequence of console clicks.

Second, it is asynchronous and serialized per product. Changes are queued and processed, and if a request is already pending on a product, other requests against that product return an error — you either retry later or cancel the first request (AWS Marketplace Catalog API docs, 2026).

The runtime path: resolve, entitle, meter

Automating the listing is the visible half. The half that actually moves money is the runtime integration between your application and AWS Marketplace, and it runs in a fixed order. When a buyer subscribes, your service receives a registration token; ResolveCustomer exchanges it for the customer’s identifiers. From there, GetEntitlements tells your app what the customer is allowed to use, and MeterUsage or BatchMeterUsage reports consumption for usage-based pricing (AWS Marketplace API Reference, 2026). If you are choosing between contract and usage models before you wire this up, our guide to AWS Marketplace metering and usage-based pricing walks through how each one changes the calls you make.

This is the path to get right first, because it is the path a buyer experiences on day one. A listing with a broken ResolveCustomer flow looks live but cannot onboard anyone.

The APIs are not busywork — they are how you keep pace with where the money is going. Forrester’s 2025 Total Economic Impact study of AWS Marketplace (commissioned by AWS) found buyers cut procurement time by 60% and solution-discovery time by 70% when purchasing through the marketplace. That speed is only an advantage if your side of the transaction can keep up, which is exactly what the runtime APIs are for.

A sane build order

You do not have to adopt every service at once, and you shouldn’t. This sequence front-loads the work that a live customer depends on and defers the work that only you see.

To make the sequencing concrete, consider a hypothetical composite: a 25-person data-tooling ISV running roughly 60 private offers a quarter entirely by hand in the console, with a second engineer pulling monthly reports to reconcile payouts. The high-leverage move for them is not to automate everything — it is to wire ResolveCustomer and metering so onboarding and billing stop being manual, then move offer creation into a change-set pipeline so offer volume no longer tracks headcount. Report reconciliation via the Agreement Service comes after, because it is internal pain, not customer-facing risk. (This example is illustrative, not a specific Automatum customer.)