How I Automated Amazon's "Request a Review" Button with the SP-API

Bobonajaf — Mon, 22 Jun 2026 16:07:13 +0000

Every Amazon order has a "Request a Review" button in Seller Central. When you click it, Amazon sends a standardised email to the buyer asking for a product review and seller feedback. It's compliant, it works, and it's tedious at scale.

I built Reevy to automate this. Here's how the SP-API Solicitations endpoint works and what I learned building around it.

The endpoint

Amazon's Selling Partner API has a Solicitations section. The key call:

POST /solicitations/v1/orders/{orderId}/solicitations/productReviewAndSellerFeedback

This triggers the exact same review request as clicking the button manually. Amazon handles the email content, language localisation, and delivery. You just tell it which order.

Authentication

SP-API uses a two-layer auth system:

Login with Amazon (LWA) — OAuth2 flow to get a refresh token from the seller
AWS IAM — your app signs requests with AWS credentials (STS AssumeRole)

The seller authorises your app once. You store their refresh token, exchange it for access tokens as needed, and sign every API call with your IAM role. Standard OAuth + AWS SigV4 — straightforward if you've done either before, a bit of a maze if you're new to both.

Eligibility rules

You can't request a review for every order. Amazon enforces:

Timing window: 5–30 days after delivery. Too early or too late and the API returns a 403.
One request per order: Call it twice and you get a 403 on the second attempt.
Order status: Must be delivered (not shipped, not cancelled, not returned).

This means you need to track delivery dates and manage a queue of eligible orders. I poll the Orders API daily, filter by delivery date, and queue orders that fall within my configured window (default: 7–14 days post-delivery).

Rate limits

The Solicitations endpoint has a rate limit of 1 request per second per seller, with a burst of 5. At scale (hundreds of orders per day per seller), this means you need to throttle your queue and handle 429 responses gracefully.

My approach: a cron job processes the queue every hour, sending requests with a 1.2-second delay between calls. Failed requests (429s, 5xx errors) go back in the queue with exponential backoff.

Multi-marketplace

A single seller often sells on Amazon US, UK, DE, FR, IT, ES, and more. Each marketplace has its own SP-API endpoint:

North America: sellingpartnerapi-na.amazon.com
Europe: sellingpartnerapi-eu.amazon.com
Far East: sellingpartnerapi-fe.amazon.com

The seller authorises once per region, and you route API calls to the correct endpoint based on the marketplace. Orders from Amazon.de go through the EU endpoint; orders from Amazon.com go through NA.

What I'd do differently

Don't poll the Orders API on a schedule. Use SP-API notifications (SQS) to get real-time order updates. I started with polling because it was simpler, but at scale the notification approach is more efficient and reduces API calls.
Store raw API responses. When something goes wrong (and it will — Amazon's API has occasional inconsistencies), having the raw response makes debugging much faster.
Test with sandbox first. SP-API has a sandbox environment. Use it before hitting production, especially for the Solicitations endpoint where a bad call can burn a seller's one-per-order request.

The product

This became Reevy — a standalone tool that automates the Request a Review button across all 21 Amazon marketplaces. Built with PHP and MariaDB, Stripe for billing, deployed on Krystal hosting. Listed in the Amazon Selling Partner Appstore.

If you're building on Amazon's SP-API and have questions about the auth flow, rate limiting, or the Solicitations endpoint specifically — happy to answer in the comments.

DEV Community: Bobonajaf