The Amazon Creators API, and what the migration actually costs you

The Amazon Creators API is what replaced the Product Advertising API. PA-API 5.0 was deprecated on 30 April 2026 and its endpoint was switched off on 15 May 2026; calls to it now return HTTP 403 pointing at the migration guide. If your product boxes went blank in May, that is why, and no amount of re-entering your old keys will bring them back.

This is a working account of the migration rather than a summary of the announcement: what actually changes in the requests, what bites during the switch, and the eligibility rule that decides whether any of it applies to you.

What changed, row by row

The headline is that this is not a version bump. Nothing written against PA-API can be pointed at the new host and expected to work; the signing, the addressing and the response shape all changed at once.

Authentication: OAuth 2.0 instead of signed requests

PA-API signed every request with AWS Signature V4 — a canonical request, a string to sign, an HMAC chain. That is gone. The Creators API uses ordinary OAuth 2.0 client credentials: you exchange your credential pair for a bearer token, then send the token.

The token endpoint is Amazon’s standard one, and it is regional:

POST https://api.amazon.com/auth/o2/token       # North America
POST https://api.amazon.co.uk/auth/o2/token     # Europe
POST https://api.amazon.co.jp/auth/o2/token     # Far East

grant_type=client_credentials
client_id=<Credential ID>
client_secret=<Credential Secret>
scope=creatorsapi::default

You get back an access token with a lifetime. Cache it — minting a fresh token on every product lookup is the most common way to burn through your rate limit doing no useful work.

Credentials come from Associates Central under Tools → Creators API. They are a Credential ID and Credential Secret, not an AWS Access Key and Secret Key, and your old PA-API keys are not convertible. Note also that the credential is per region, so a publisher working across Europe and North America holds two pairs. Which stores that covers is worth checking before you apply: the marketplace lookup lists all twenty-two.

One host, and the marketplace moves into a header

PA-API had a host per marketplace: webservices.amazon.com, webservices.amazon.co.uk, webservices.amazon.de and so on. Choosing a store meant choosing a hostname.

Now there is one host, creatorsapi.amazon, and the target store travels in an x-marketplace request header instead. Operations sit under a catalog path, and the two you will use are getItems for known ASINs and searchItems for keyword lookups.

The response shape, and the two things that bite

Response keys moved from PascalCase to lowerCamelCase throughout. ItemInfo became itemInfo, Images.Primary.Large became images.primary.large. Mechanical, tedious, and easy to catch because everything fails at once.

Two changes are less obvious and will pass a quick test before failing in production.

• Offers became offersV2, and amounts sit one level deeper. Where you used to read a price directly, there is now a money object between you and the number. A client that reads the old path gets null rather than an error, so the box renders — without a price.
• Your cache is poisoned. Anything stored under the old keys is PascalCase and unreadable to the new client. Give the new cache a different key prefix rather than reusing the old one; entries then get ignored instead of half-parsed. The same goes for any stored “last known good” payload.

The resource names you request follow the same pattern — images.primary.highRes, itemInfo.byLineInfo, offersV2.listings.price, offersV2.listings.availability. Ask for what you render and nothing more; every extra resource is payload you pay for in latency.

The whole migration on one screen, for the developer who wants the mapping rather than the reasoning:

	PA-API 5.0	Creators API
Credentials	Access Key and Secret Key	Credential ID and Credential Secret — not convertible
Signing	AWS Signature V4 per request	OAuth 2.0 client credentials, then a bearer token
Host	One per marketplace	creatorsapi.amazon, for all of them
Target store	Chosen by hostname	x-marketplace request header
Operations	GetItems, SearchItems	getItems, searchItems, under a catalog path
Response keys	PascalCase	lowerCamelCase throughout
Credential scope	One pair, all marketplaces	One pair per region
Eligibility	Three sales, then keys	Recent qualifying sales, checked continuously

What to do when it returns something other than 200

The failure modes are few and they mean different things. Treating them all as “retry later” is how an integration ends up hammering an endpoint that will never answer it.

What comes back	What it means	What to do
429	Too many requests. The allowance is generous but finite.	Back off and lengthen the pause. Do not retry immediately in a loop.
401 or 403	Token expired, wrong region, or the account no longer qualifies.	Refresh the token once. If it fails again, check eligibility rather than the code.
200 with no price	Normal. Not every item exposes an offer to the API.	Render the box without a price rather than treating it as an error.
200, empty result	Usually the wrong x-marketplace for that ASIN.	Check the header before you check the ASIN — the same product has different ASINs per store.

The one worth designing around is the last: an ASIN that exists on amazon.com frequently does not exist on amazon.de, and the API answers that with a polite empty list rather than an error. Which store serves which country, if you are deciding what to request.

The eligibility rule that decides everything

All of the above is irrelevant if you cannot get a credential, and the bar rose with the migration.

PA-API asked for three referred sales, once, and then generally left you alone. Access to the Creators API is reported to require ten qualified referral sales in the previous thirty days, assessed on a rolling basis rather than granted permanently.

For a large site that is invisible. For a small one it is the whole story: a quiet August, a seasonal dip or a ranking wobble can take your product data away in the month you can least afford it. And the loop closes on itself, because product images and live prices are part of what makes a page convert in the first place.

The practical conclusion is not “give up on the API” but “do not let a page depend on it”. A product box that renders what you typed when the API is unavailable is worth more than one that fetches perfect data nine months a year and shows an empty frame in the other three. If you are still working toward your first sales, the piece on Amazon Associates requirements covers that ladder from the bottom.

Two rules people migrate straight past

Prices and availability must be refreshed at least daily. This is an Operating Agreement requirement, not a performance suggestion, and it constrains your cache. Caching aggressively is the obvious way to stay inside a rate limit — but a cached price older than a day is a compliance problem, not a stale pixel. Cap any “serve the last good response” fallback at twenty-four hours for exactly this reason.

HTTP 429 means back off, not retry. Rate limiting returns 429, and hammering it makes the throttle worse rather than better. A client that retries immediately turns a brief limit into a long one. Fail soft, serve what you had, and try again later.

If you use a plugin rather than write code

Then the question is only whether whoever makes it has done the work. Three checks:

• Does its settings screen ask for a Credential ID, or still for an Access Key? The wording gives it away immediately.
• Was there a release after May 2026? A plugin that has not shipped since the switch-off cannot be talking to anything.
• What does it show when the API is unavailable? Ask before you need to know. The answer should be “what you typed”, not “nothing”.

The disclosure, since this is our site: Doozly talks to the Creators API, and does so in the free version — connect a credential if you have one, and if you do not, it builds tagged product boxes from what you type with no credential at all — which below the ten-sales bar is the whole point rather than a limitation. Several other plugins have migrated too, and if yours has, you have nothing to do.

The wider lesson is the one in the SiteStripe piece: this is the second time in three years that Amazon has withdrawn the way affiliates get product data and named a replacement with a higher bar. Whatever you build on, the thing that matters is that somebody keeps it current for you.

Common questions

In one paragraph: new credentials from Associates Central, OAuth instead of signed requests, one host with the marketplace in a header, camelCase everywhere, prices a level deeper under offersV2, a fresh cache prefix, and ten sales every thirty days to keep the door open. The plumbing is a day of work. The eligibility rule is the part worth designing around.