← Blog

2026-06-11

Engineering

We Created and Managed Our AWS Marketplace Listing with Claude Code

By Michael Cooper · Founder

Between June 6 and June 9 we took AGLedger Enterprise's container listing on AWS Marketplace from rough draft to submitted-for-Public, and nearly every operation along the way was performed by Claude Code working in a terminal against the Marketplace APIs. The agent wrote the listing copy, set the real pricing, shipped the v1.0.0 delivery option, validated the licensing integration against a live entitlement — including the standard self-purchase test sellers run before a new offer goes live — fixed the four bugs that validation surfaced, caught a buyer-facing error in our own usage instructions, and submitted the listing into AWS's Seller-Ops review. We opened the Management Portal console a handful of times, mostly to look at things.

Listing on AWS Marketplace has usually meant one of two things: working through the Management Portal yourself, or working with a cloud go-to-market platform that operates marketplaces for you. As of this spring there is a third, standalone option: a coding agent driving the Marketplace APIs directly. It is not free — you bring a Claude subscription, an AWS seller account, and your own judgment at a few specific moments — but it is real, and we have not found another published account of anyone doing it end-to-end. This post is what it looked like. The mechanics live in two companions: a how-to for running the same workflow and the API reference this post leans on throughout.

Why this only recently became possible

The seller half of the surface is not new: the Catalog API has handled listing changes through asynchronous change sets for years. What was missing was the buyer half. You cannot finish a listing without validating it the way a buyer will experience it, and validating a paid product means purchasing it — which, until this spring, meant clicking through the console. The Discovery API (April 2026) and Agreements API (May 2026) closed that loop: read the offer and its terms, then purchase with CreateAgreementRequest → AcceptAgreementRequest. With both halves scriptable, the whole lifecycle — write the listing, price it, ship a version, buy it, test it, take it public — fits inside one agent session.

A detail that says something about agent-driven work: our installed aws-cli predated both new services, so the commands simply did not exist on the machine. Claude Code hit the missing commands and switched to the npm SDK clients (@aws-sdk/client-marketplace-discovery, @aws-sdk/client-marketplace-agreement). That kind of dead-end-and-reroute is exactly the part of API work that used to consume an afternoon.

The seller side: change sets are an agent-shaped workflow

Every seller mutation on AWS Marketplace — copy, pricing, dimensions, versions, visibility — is an asynchronous change set: submit StartChangeSet, poll DescribeChangeSet, and read the per-change ErrorDetailListwhen something fails. That loop — submit, read the refusal, adjust, resubmit — is precisely the loop coding agents are good at, and the errors arrived on schedule. The change-set name field rejects parentheses. Usage instructions reject any non-ASCII character; one em-dash fails the whole change set. Marketplace ECR accepts plain image manifests only, so our Sigstore-signed artifacts had to stay on the public registry while the image itself was mirrored in by digest. Each refusal is terse, and each is now a row in the error-to-cause table the agent helped assemble.

The buyer side: validating the listing by purchasing it

Before a paid listing goes public, the seller is expected to test the purchase path on their own account — AWS documents the pattern: temporarily reduce the price, buy your own Limited-visibility product, validate, restore the price. The agent ran all of it. One UpdatePricingTerms change set dropped every rate card to $0.01 — after saving the original terms JSON, because that operation replaces pricing wholesale and the restore would need to restate every card verbatim. Then the four-step buyer flow: GetOffer, GetOfferTerms, CreateAgreementRequest, AcceptAgreementRequest.

The human gate sits between the last two steps. CreateAgreementRequest returns a chargeSummary showing the exact charge before anything is committed, and an agent that is about to spend money should surface the quote and wait. Ours did: "newAgreementValue": "0.01", approved, then accepted. The agreement went ACTIVE immediately and the entitlement reached PROVISIONED about two minutes later. We were our own customer, and the real test could start.

What the live run found

Our License Manager integration — the CheckoutLicensecall a customer's cluster makes at startup to prove it bought the product — had sixteen passing unit tests and had never once run against the real AWS API. Against the live entitlement it turned out to be wrong four times in one ~30-line function: an idempotency token that locked retries out for a day, a checkout type the mocks had asserted was correct (the test suite required the bug), the product code passed where the product IDbelonged, and a counted entitlement held for its full 60-minute TTL instead of being checked back in. Every one was found the same way: run the real call, read the real refusal, inspect the real issued license. The full semantics — and the five distinct causes hiding behind NoEntitlementsAllowedException— are in the reference. The fixes went in, the unit tests were rewritten to pin the live-verified shapes, all five validation scenarios passed against live AWS, and the original pricing was restored from the saved JSON.

The same discipline then caught a bug that was not in code at all. The first Public submission was already in flight when a review pass walked through our buyer-facing usage instructions exactly as a buyer would — and found they fail on the first command, composing a doubled image tag the container runtime rejects. AWS's reviewers verify that usage instructions work end-to-end, so this would otherwise have surfaced weeks later as a failed audit. We cancelled the submission inside the window where that is still possible, fixed the instructions, hardened the installer against the input, and resubmitted.

Where the human stayed in the loop

Three places, by design. Approving the purchase — any AcceptAgreementRequestmoves money, however little. Approving the Public submission — UpdateVisibilityhands the listing to a manual review of up to 37 days and locks it against all other changes for the duration, which is not a decision an agent should make alone. And the copy itself — the agent drafted and revised the listing text, but positioning is a founder call. Everything else — the change-set loop, the error diagnosis, the validation matrix, the price-restore — the agent did and verified itself.

An honest accounting

What it took: a Claude subscription, an AWS account already registered as a seller, and intermittent sessions across three days — the validation arc in the middle ran about 75 minutes end-to-end. Marketplace spend was one cent, which is what the documented self-test pattern costs anyone. What it did not replace: seller registration, the public seller profile, and banking and tax setup are still portal-only, and the Seller-Ops review at the end is still performed by people at AWS on their schedule. And if what you actually want is a partner operating cloud go-to-market across marketplaces — private offers, co-sell, renewals at scale — that is what platforms like Tackle and Clazar are built for, and a coding agent in a terminal is not that.

What is new is the standalone option in between: a team that lives in the terminal can now operate its own listing the way it operates the rest of its infrastructure — as code, with an agent doing the mechanical work and a human approving the moments that matter. The pattern that made it work is the same one that found every bug along the way: stop trusting what you wrote, and check what the customer will actually run.

As of publication, the listing is in Seller-Ops review. If you want to run the same workflow, start with the how-to; if you want the API surface itself, the reference is the canonical page.

Sources & Further Reading

Related