Creating and managing AWS Marketplace listings with Claude Code

A coding agent with scoped AWS credentials can operate an AWS Marketplace listing end-to-end: write and revise the listing copy, manage pricing, ship new versions, validate the buyer experience with the standard self-purchase test, and submit the listing for Public review. This page is the how-to for running that workflow with Claude Code — what to set up, what to ask, and where a human must stay in the loop. Every step from listing copy to the Public submission was run live against our own production container listing; the narrative account is in the companion post, and the underlying API semantics live in the AWS Marketplace API reference.

Position it honestly: this is a third, standalone way to operate a Marketplace presence, alongside working the Management Portal by hand and working with a cloud go-to-market platform. It is not free — it costs a Claude subscription, scoped AWS access, and your attention at three approval gates — and it suits teams that already run their infrastructure from the terminal.

What can the agent do, and what stays manual?

All Marketplace API operations run in us-east-1.

What access do you give the agent?

Grant in stages, least privilege first — the same way you would onboard a new operator.

• Read-only to start: the AWSMarketplaceSellerProductsReadOnly managed policy lets the agent run ListEntities / DescribeEntity / ListChangeSets / DescribeChangeSet and learn the current state of the listing before it can touch anything.
• Mutations, scoped: grant aws-marketplace:StartChangeSet on the specific entity ARN plus a ChangeSet ARN with a /*wildcard — a fresh change-set ID is minted per request, so the wildcard is required. You can additionally restrict which change types the agent may submit with the catalog:ChangeType condition key (for example, allow UpdateInformation but not UpdateVisibility, keeping the Public submission behind a separate credential). ARN shapes and the condition key are in Access control for the Catalog API. The blunt alternative is AWSMarketplaceSellerFullAccess.
• Buyer side, for validation only: the agreement and discovery actions (CreateAgreementRequest, AcceptAgreementRequest and the Discovery reads) plus, for runtime license testing, license-manager:CheckoutLicense / CheckInLicense / GetLicense and the service-linked role:

aws iam create-service-linked-role --aws-service-name license-manager.amazonaws.com

Give Claude Code the credentials as a named profile (AWS_PROFILE) rather than pasting keys into the session, and keep its command-approval prompt on for mutating awscalls — the approval gates below depend on it.

How do you brief the agent?

Two things make the difference between an agent that operates the APIs and one that guesses at them:

• Give it the reference before the task. Marketplace errors are terse, the semantics are spread across several AWS doc sets, and a few load-bearing facts (which identifier ProductSKU wants, which CheckoutType matches which license shape) are documented in single parentheticals. We publish the consolidated reference as plain markdown for exactly this use:

curl -O https://agledger.ai/recipes/aws-marketplace-api.md
# then: "Read aws-marketplace-api.md before touching the listing."

• State the standing rules once, up front. Ours: never accept an agreement without showing the chargeSummary and getting approval; save the current pricing terms JSON to a file before any UpdatePricingTerms; show a diff of any listing copy against DescribeEntity output before submitting; never submit UpdateVisibility without an explicit go.

The working loop: change sets

Every seller mutation is an asynchronous change set, and the agent's loop is always the same: submit, poll, read the refusal, adjust, resubmit.

# discover the listing
aws marketplace-catalog list-entities \
  --catalog AWSMarketplace --entity-type ContainerProduct --region us-east-1

# read its current state (copy, dimensions, versions)
aws marketplace-catalog describe-entity \
  --catalog AWSMarketplace --entity-id <entity-id> --region us-east-1

# after StartChangeSet: poll until terminal
aws marketplace-catalog describe-change-set \
  --catalog AWSMarketplace --change-set-id <change-set-id> --region us-east-1

Statuses run PREPARING → APPLYING → SUCCEEDED, or end in FAILED with a per-change ErrorDetailList— which is where the agent earns its keep, because it reads the error, consults the error-to-cause table, and fixes the payload instead of asking you what happened. Two lifecycle facts to keep in the agent's context: a change set can be cancelled only while PREPARING, and an entity is locked while a change set runs against it (a concurrent submission returns ResourceInUseException, HTTP 423).

The task playbook

1. Write or update the listing copy

UpdateInformationis a PATCH — omitted fields keep their previous values, so a targeted edit cannot blank your logo or highlights. Have the agent pull current state with DescribeEntity, draft against the field limits (Title ≤ 72, ShortDescription ≤ 1000, LongDescription ≤ 5000, Highlights ≤ 3), and show you the diff before submitting.

2. Change pricing

UpdatePricingTerms replaces pricing terms wholesale— any rate card you do not restate is deleted. The standing rule that makes this safe for an agent: save the complete current terms JSON to a file before every pricing change set, so any change can be reverted by re-applying the saved document verbatim. This is also exactly the mechanism the self-purchase test uses.

3. Ship a new version

AddDeliveryOptions ships a product version and its container delivery option. The constraints that reject change sets in practice: Marketplace ECR accepts plain Image Manifest V2 images only (mirror your image in by digest; Sigstore signatures and attestation artifacts stay on your public registry, or you get UNSUPPORTED_CONTAINER_IMAGE_URI); no mutable tags; the buyer-facing usage instructions must be ASCII-only (a single em-dash fails with INVALID_USAGE_INSTRUCTIONS, whichever change type carries them); and every submission triggers an automated layer scan — expect the change set to sit in PREPARING for a while, and budget time to fix findings.

4. Validate by buying it

The standard pre-listing test is buying your own product, and AWS documents the pattern for Limited-visibility listings: drop every rate card to $0.01 with one UpdatePricingTerms change set (after saving the original JSON), purchase through the Discovery + Agreements buyer flow, validate, then restore the saved pricing verbatim. The approval gate is built into the API: CreateAgreementRequest returns a chargeSummary with the exact charge before anything commits, and the agent stops there until you approve; only AcceptAgreementRequest moves money. After accepting, the readiness signal is GetAgreementEntitlements reaching PROVISIONED(typically ~90 seconds) — not the seller-side marketplace-entitlement get-entitlements, which lags.

Then validate what you actually shipped: run the real entitlement check (CheckoutLicensefor contract pricing) against the live entitlement, and walk through your own usage instructions exactly as a buyer would. Both checks found real bugs on our listing, four of them blessed by sixteen green unit tests — the companion post is the account.

5. Go Public

The submission is one change set — UpdateVisibility with {"TargetVisibility": "Public"}— but it is a human decision, not an agent task. It must be alone in its own change set, it triggers a manual Seller-Ops review of up to 37 days, and it locks the product against all other changes for the entire window — so land every copy, version, and pricing change first. The agent's job here is the pre-flight: verify the listing state, execute the usage instructions one final time, submit on your explicit go, and know that the submission can still be cancelled while the change set is PREPARING if something surfaces late.

Where must a human stay in the loop?

• Money: every AcceptAgreementRequest, regardless of amount. The chargeSummary quote step exists; use it as the gate.
• The Public submission: it starts a 37-day clock and locks the listing. Explicit human go, every time.
• Buyer-facing copy: the agent drafts and verifies; what your listing promises is a business decision.

Everything else — the change-set loop, error diagnosis, propagation polling, the validation matrix, the pricing restore — is mechanical work the agent runs and verifies itself.

What does it cost?

AWS charges nothing to create or maintain a listing; marketplace fees apply only when the product transacts. The agent path costs a Claude subscription or API usage, one cent for the self-purchase test, and your attention at the three gates above. Choose it the way you would choose any operating model: the Management Portal is fine for a one-time listing you will rarely touch; a cloud go-to-market platform is the right call when you want a partner running marketplace operations across clouds; the agent path fits teams that already operate their infrastructure from the terminal and want the listing managed the same way — as code, with verification built into every step.

FAQ

Sources

• Listing, buying, and licensing a product on AWS Marketplace programmatically — the companion API reference: service ownership, change-set lifecycle, buyer flow, CheckoutLicense semantics, error-to-cause table
• Using the AWS Marketplace Catalog API — change-set workflow and status values
• Access control for the Catalog API — managed policies, granular StartChangeSet, the catalog:ChangeType condition key
• AWS Marketplace now supports programmatic procurement with Agreements API — May 2026
• AWS Marketplace Discovery API for programmatic access to catalog data — April 2026
• Getting started with container products — Limited visibility, the reduced-price self-test pattern, the layer scan, going Public
• Contract pricing for container products with AWS License Manager — buyer IAM, floating licenses