What Amazon's Request a Review button actually sends

The button is not an exemption from the messaging rules. It is one of the four channels those rules name. Which means everything sellers argue about in forums — when the button appears, why it greys out, whether you may follow up afterwards — is written down. It is simply written down in two documents that nobody reads, because neither of them looks like a seller help page.

Where the rules for this button actually live

Amazon's help page for the button sits behind the Seller Central sign-in, which is why almost every article about it cites other articles. But the button is not undocumented. It appears by name in the Communication Guidelines, in the paragraph that defines what a proactive message is:

Read the list again: template, extension, application, API. Four ways to send the same class of message, governed by one set of rules. The button is not safer because it is a button. It is safer because of what Amazon puts into the message on your behalf — which is the next quote, and the one that retires a whole genre of second-hand advice.

What Amazon fills in, and what you give up

The claim that the button translates itself into the buyer's language is usually sourced to seller blogs quoting each other. It does not have to be: it is in the policy, alongside the two other requirements that trip people up when they write their own messages. Proactive messages must carry the 17-digit order ID and must be in the buyer's Language of Preference. Through the button, both are automatic. Through your own text, both are your problem.

What you are handing over in exchange is stated just as plainly on the developer side, where Amazon documents the same mechanism for applications:

Template-based is the whole story. You cannot add a sentence, cannot reference the replacement you shipped last week, cannot attach anything, and cannot ask for one of the two things rather than both. The button offers a specific trade: you give up every word in the message in exchange for never being wrong about any of them. For most orders that is a good trade. The section after next is about the orders where it is not.

The window is not "5 to 30 days after delivery"

That phrasing is everywhere, and it is a paraphrase of something more specific. Amazon states the window in the setup guide for the API behind the button:

Those two field names are not decoration. Amazon defines them in the Orders API, and the definition is the part worth reading twice:

There is a second clock, and it is anchored somewhere else again: "Proactive Permitted Messages must be sent within 30 days of order completion." Order completion is not delivery, and delivery is not the delivery estimate. Our reading — and it is a reading, not a rule Amazon states — is to treat whichever window closes first as the real deadline, and to stop treating a greyed-out button as a bug. A button that will not press is usually a clock you were measuring from the wrong event.

One more detail for anyone automating this rather than clicking: those two delivery fields are documented as returned only for seller-fulfilled orders. If your inventory is FBA, the fields the setup guide tells you to check are not the ones you will get back. The eligibility call exists for exactly this reason — ask Amazon whether the order is eligible instead of computing it.

One press spends the only request that order gets

This is the cost that never appears in the tutorials, because a button that costs nothing to click feels free. It is not. The Communication Guidelines list seven message types that are not Permitted Messages at all, and the seventh is short:

The developer documentation says the same thing as an instruction — "Send only one productReviewAndSellerFeedback or free form proactive message per order" — and then describes what happens when you ignore it:

Note what that sentence proves in passing: the button and the API are not two features that happen to resemble each other. They share one budget, and each knows what the other spent.

What is not closed off is the rest of buyer-seller messaging. The prohibition is on a repeat request for a review or feedback, not on ever contacting that buyer again. Amazon's own list of valid reasons for a proactive message stays open: resolving an issue with order fulfilment, requesting information needed to complete the order, a return-related question, an invoice, scheduling a heavy delivery, verifying a custom design. The messaging rules guide walks through each of those with the wording that keeps them compliant.

It asks for two things, and only one of them can cost you the account

Amazon's description of the operation is a single sentence, and the word and is doing more work than sellers notice: it "sends a solicitation to a buyer asking for seller feedback and a product review for the specified order."

Those are different objects with different consequences, and you cannot ask for one without the other:

Quotes above from Amazon, Order Defect Rate (PDF, Amazon-hosted).

So the button is not risk-symmetric. On a satisfied buyer it is close to free money. On a buyer with an unresolved grievance, it is an invitation to file the version of that grievance that counts against a metric with a 1% ceiling. Neither Amazon nor anyone else will warn you which of the two you are pressing on. If it goes the wrong way, the removal criteria are narrow and worth knowing in advance.

So when should you press it?

The honest summary is that the button is excellent and blind, and those two facts are not in tension.

Knowing who you are pressing it on

Here is the shape of the problem, stated plainly. Satisfied buyers rarely think to leave a review. Dissatisfied ones rarely forget. So the button asks a question whose answer skews against you exactly when you know least about the order. In practice sellers land on one of two habits: never press it, and leave real reviews uncollected; or press everything, and occasionally remind someone who had quietly decided not to bother.

Both habits are the same bet placed blind. The only thing that changes the odds is finding out what the buyer thinks before the button is pressed — which is what our product does, and it is worth being precise about how, because this is a category with a lot of non-compliant practice in it.

A card in the box. The buyer scans it and lands on a page that carries your brand, in their own language. No Amazon account, no API authorisation, no password shared with anyone. They tell you how it went. Every buyer sees the same page, whatever they are about to say, and a buyer who leaves no review at all can still complete it. Nothing is offered in exchange — no cashback, no gift, no discount. Nobody is ever asked to change or remove a review. Those are not marketing lines; they are the constraints that keep the whole approach on the right side of the insert card rules.

Then the Chrome extension puts that back where the decision is made. On the Seller Central order page it shows a small card: which orders are waiting, the buyer on this one, and a button that presses Amazon's own Request a Review — the same official mechanism this whole guide is about, not a workaround. It does not sort your buyers for you: on the standard product the server does not send the extension a star rating at all, the queue is not filtered by rating, and an order nobody scanned can still be requested. The decision stays yours. It is just no longer blind.

If you would rather see it before signing up: the demo walks through the page a buyer actually scans into, in about ten seconds.

If you automate it

Three things from the documentation, for anyone wiring this into an ERP or a script rather than clicking:

• Ask, do not calculate. "To check eligibility programmatically before you send a solicitation, use the getSolicitationActionsForOrder operation." If the productReviewAndSellerFeedback action is not in the response, the order is not eligible, and no amount of date arithmetic on your side changes that.
• The rate limit is low on purpose — 1 request per second, burst of 5. This is not a channel for blasting a backlog.
• 403 means already spent, not broken. Treat it as a terminal state for that order and stop retrying.

And one sentence from the end of the Communication Guidelines that deserves to be the last word, because it explains what the button is for in Amazon's own view of the world:

Being restricted to Amazon's templates is listed as a penalty. The button is simultaneously the safest tool you have and the thing you are left with when the safer tools are taken away. Sellers who use it deliberately never find out which of the two it is for them.

Frequently asked questions

Is Amazon's Request a Review button safe to use?

It is as safe as a review request gets, because you did not write it. Amazon's Communication Guidelines name the Request a Review page in Seller Central as one of the channels for a proactive Permitted Message, and state that sending through Amazon's templates automates the inclusion of the order ID, Language of Preference translation and critical message guidelines. The wording risk that gets sellers suspended — incentives, conditional asks, promotional language — is not available to you through the button. What the button does not protect you from is timing and judgement: it still spends your one request for that order.

How long do I have to press the Request a Review button?

Two different clocks are documented, and they are anchored to different events. The Communication Guidelines state that proactive Permitted Messages must be sent within 30 days of order completion. Amazon's Solicitations API — the mechanism the button rides on — states that you can request a solicitation within a time frame of five days after the EarliestDeliveryDate to 30 days after the LatestDeliveryDate. Those two fields are Amazon's term for the delivery period you committed to, not the day the parcel actually arrived, so the practical window moves with your delivery promise.

Can I use the Request a Review button twice on the same order?

No. The Communication Guidelines list "A repeat request (per order) for a product review or seller feedback" among the message types that are not Permitted Messages at all, and Amazon's developer documentation states that a second API attempt for the same order returns a 403 status code, while clicking the button in Seller Central after an API send returns an error saying a review was already requested. The limit is enforced, not merely advised.

Can I edit the wording of the Request a Review message?

No. Amazon describes the mechanism as sending a single template-based email, and the template is Amazon's. You cannot add context, reference a problem you solved, attach anything, or ask for one of the two things rather than both. That is the trade the button offers: you give up every word in exchange for never being wrong about any of them.

Does the button ask for a product review or for seller feedback?

Both, in one email. Amazon's own description of the operation behind it is that it sends a solicitation to a buyer asking for seller feedback and a product review for the specified order. You cannot request only one. This matters more than it sounds, because the two land in different places: a product review sits on your listing, while negative seller feedback feeds your Negative Feedback Rate, which is one of the three components of Order Defect Rate.

Does using the button stop me from messaging that buyer again?

It stops you asking again for a review or feedback on that order. It does not close buyer-seller messaging for the other reasons Amazon lists — resolving an issue with order fulfilment, asking a return-related question, sending an invoice, verifying a custom design, and the rest. Note what is prohibited regardless of how many messages you have sent: a message that says only thank you, or only that you are there to help if there are any problems, is on the not-permitted list on its own.

Should I press it on an order where the buyer already complained?

Weigh what you are inviting. The button asks an unhappy buyer for seller feedback as well as a product review, and one- and two-star seller feedback is what Amazon counts as negative in a metric that can deactivate an account above 1%. Nothing in policy stops you pressing it, and no rule says a resolved complaint stays resolved. The honest version is that on a shaky order the button is a coin-flip you initiated, and the only way to improve those odds is to know what the buyer thinks before you press it rather than after.

Related: Amazon buyer-seller messaging rules — what you can send · How to remove negative seller feedback · Amazon review and insert card rules: the official wording, sourced · What are bad reviews costing you? — free calculator