Reverse keyword lookup is one operation: give it an ASIN, get back the terms that product shows up for in search.
It looks simple enough that few people check what actually comes back. Skip that check and every judgment built on those terms is skewed from the start.
What the response actually contains
The items.keyword field is defined in the docs as:
Terms this ASIN reached the first 3 pages of Amazon search results for, in the last 30 days or a given calendar month
There are two qualifiers in that sentence and both matter.
First, it is "first 3 pages," not "all." If the ASIN sits on page 8 for a term, that term is not in the response. So the result is not "every keyword relevant to this product" — it is "every keyword this product has meaningful visibility on."
Second, it is a snapshot over a window. Without month you get the last 30 days; with month (format yyyyMM) you get a specific past calendar month.
Together those explain a common confusion: a new or weakly ranked listing returns very few terms, and that is not a data problem. It accurately reports one thing — this is how much visibility the product currently has. Conversely, running a well-established ASIN and getting back a thousand terms is equally normal.
Which makes the count itself a metric. If a competitor returns 1,800 terms and you return 90, that gap is already part of the conclusion and needs no further analysis.
What one request takes
| Parameter | Required | Note |
|---|---|---|
asin | Yes | A single ASIN, ten uppercase letters and digits |
marketplace | No | Defaults to US |
month | No | Past calendar month as yyyyMM; omit for the last 30 days |
page | No | Page number, up to 100 |
size | No | Items per page, up to 100 |
Note that asin is singular rather than a list — batching happens on your side, in a loop, which matters for estimating call volume. Twenty competitors is at least twenty calls, multiplied again by pages if you need to page through each.
There is a pagination ceiling, and it changes conclusions
The endpoint retrieves at most 2,000 records. The total field in the response is the total number of matching terms, and it can be larger than 2,000.
When those two numbers disagree, you have the first 2,000 — not all of them.
The practical consequence: you have to care about ordering, because what gets cut is the tail. If you are hunting high-value terms, losing the tail hardly matters. If you are measuring "how many terms does this ASIN cover," total is that number — not the count of rows you actually pulled.
Recording both is more reliable than recording one.
How to read the rank fields
Every term carries two rank objects, rankPosition (organic) and adPosition (advertising), with the same shape:
| Field | Meaning |
|---|---|
page | Which page |
pageSize | How many results on that page |
index | Position within the current page |
position | Position across all results |
updatedTime | When this rank was measured |
Compare on position, not on page. pageSize is not fixed — results per page can differ by marketplace and by search term. Whether page 2 slot 1 beats page 1 slot 60 cannot be answered from page numbers alone, and position answers it directly.
updatedTime deserves its own column. Ranks move, and a rank number with no timestamp cannot be judged fit for use two weeks later.
Also, rankPosition and adPosition both being present means you hold an organic position for that term and are advertising on it. Only adPosition means the visibility is purchased. How to optimize Amazon keywords covers what to do about that distinction.
badges: where the term places you
badges is an array whose values include naturalSearching, amazonChoice, editorialRecommendations, fourStar, highlyRated, sponsorBrand, sponsorVideo and ads.
It answers where the visibility comes from. "This term gets impressions" means something very different coming from organic results than from an ad slot. The column earns its keep in competitor analysis especially: whether a rival's position on a term is earned or bought is readable straight off the badges.
Looking up yourself and looking up competitors is one endpoint
The lookup does not care whose ASIN it is. Same endpoint, two uses:
Look up yourself to answer "which terms am I getting impressions for." That is where optimization starts.
Look up competitors to answer "which terms do they hold position on." The usual approach is to run three to five comparable rivals, union the returned terms, then subtract your own — the difference is your blind-spot list.
One caveat on that method: a competitor's terms are not automatically right for you. They may carry variants, sizes or certifications you do not, making some terms relevant to them and not to you. The difference is a candidate list, not a to-do list.
Three common misreadings
One: the returned terms are the competitor's backend search terms. They are not. Backend search terms are filled in by the seller and visible only to that account as authorized data. The lookup returns terms the ASIN actually appeared for in public search results. Different sources, and no correspondence between them.
Two: more terms means a better product. More terms means broader visibility. A term that never produces an order mainly earns its place in your list as something to exclude. Count and quality are separate readings.
Three: one lookup is enough.
A lookup is a snapshot. Judging a trend needs several points in time — pulling a few consecutive calendar months via month says considerably more than any single result.
Once you have the terms
The lookup is only retrieval. Two directions follow:
- To merge these terms into a maintainable library, see Building your own keyword library
- To decide what to do with each term, see How to optimize Amazon keywords
Questions
Can I pass several ASINs at once?
The reverse lookup's asin parameter is singular, so batching means looping on your side.
Do parent and child ASINs return the same terms? Not necessarily. Visibility can differ between variations, especially in categories where size or color vary widely. For a rigorous comparison, record which ASIN you queried rather than writing "this product" loosely.
Why does the rank differ from what I see when I search manually?
Search results depend on location, sign-in state, prior behavior and timing, so a manual search can rarely reproduce the endpoint's sampling conditions. Judge freshness with updatedTime instead of trying to "verify" it by hand.
How far back does history go?
The month parameter takes a calendar month. Check the endpoint documentation for the range actually available rather than assuming any arbitrarily old month has data.