Amazon API 502 Retry: Fixing Offers, Bestsellers and Deals Retry Logic

The fix for an amazon api 502 retry on /amazon-product-offers, /amazon-bestsellers or /amazon-deals is to trust the status code: since the 2026-09-19 Lambda deploy, a page these three endpoints could not read answers a retryable billed 5xx, not the misleading 200 with a zero price or an empty list they used to send. Retry the 5xx up to three times with backoff, and stop treating a genuine 0.0 price or empty list in a 200 response as a sign to retry.

What changed in the 2026-09-19 Lambda deploy?

Before the deploy, a page these three endpoints could not parse still answered 200: offers sent buyBox.totalPrice 0.0 as if no price had been read, and bestsellers/deals sent an empty array as if the category or deals page simply had nothing on it. Both looked identical to a real answer, so a client had no status code to react to and either accepted bad data or added its own heuristic (a price of exactly 0.0, a suspiciously empty list) to guess at a failure. Since the deploy, the same unreadable page answers a retryable billed 5xx instead, mostly 502. The table below is the before/after for amazon api 502 retry on these three endpoints.

Which status codes should a client retry here?

Retry 429, 502 and 503 on these three endpoints: 429 is the free per-key concurrency cap (wait Retry-After), 502 and 503 are billed on every attempt, so cap the attempts and back off between them. A 404 (the ASIN or seller is not on that marketplace) is a real, billed answer and retrying it only buys the same answer again. A 401/403 means the key or the credits are the problem, not the page, so stop immediately instead of looping. The retry wrapper below is the same get_with_retry and RETRYABLE set from the Python API quickstart, which defaults to 4 attempts; the example here passes attempts=3, because the Lambda has already retried once internally by the time your client sees a 502, so a 4th client attempt mostly pays for the same dead page again.

offers_bestsellers_deals.py - trusts the 5xx, never the old zero/empty heuristic

"""Client wrapper for /amazon-product-offers, /amazon-bestsellers, /amazon-deals.

Since the 2026-09-19 Lambda deploy these three endpoints answer a retryable
billed 5xx (mostly 502) when the page could not be read, instead of a 200
with a misleading empty/zero result. A parse exception inside the Lambda is
itself retried once upstream before it ever reaches the client, so the
client no longer needs the old 5-7 attempt loops some scripts used - 3 is
plenty, and a 4th attempt only pays for a request that is very unlikely to
turn into data.
"""
from retry import get_with_retry
from sellermagnet import ApiError, new_session

MARKETPLACE = "ATVPDKIKX0DER"  # amazon.com


def offer_price(session, asin: str) -> dict:
    """Real Buy Box price, including a genuine 0.0 (the API never sends that for a failed read now)."""
    data = get_with_retry(session, "amazon-product-offers", attempts=3, asin=asin, marketplaceId=MARKETPLACE)
    box = data["buyBox"]
    return {"asin": asin, "price": round(box["totalPrice"], 2), "seller": box.get("sellerId"), "offers": len(data["offers"])}


def bestseller_page(session, category_id: str, count: int = 50) -> list:
    """An empty list here is real: a short category page, not a failed fetch (those now raise)."""
    data = get_with_retry(session, "amazon-bestsellers", attempts=3, category_id=category_id,
                           marketplaceId=MARKETPLACE, count=count)
    return data["bestsellers"]


def deals_page(session, category_id: str, count: int = 50) -> list:
    """Same rule as bestsellers: a real empty page is billed data, a broken page is now a 5xx."""
    data = get_with_retry(session, "amazon-deals", attempts=3, category_id=category_id,
                           marketplaceId=MARKETPLACE, count=count)
    return data["deals"]


def is_false_failure(result: dict | list) -> bool:
    """The pre-2026-09-19 heuristic some scripts still carry: zero price / empty list means 'try again'.

    Keep this ONLY to flag old logic in a code review; do not call it on real responses.
    A genuine 0.0 totalPrice or a genuine empty list is now valid, billed data: the API already
    turned an unreadable page into a 5xx that get_with_retry caught before you see a result at all.
    """
    if isinstance(result, dict):
        return result.get("price") == 0.0
    return len(result) == 0


if __name__ == "__main__":
    s = new_session()
    try:
        offer = offer_price(s, "B0CL61F39H")
    except ApiError as err:
        offer = {"error": f"{err.status}: {err}"}
    try:
        deals = deals_page(s, "electronics")
    except ApiError as err:
        deals = {"error": f"{err.status}: {err}"}
    print(offer)
    print("deals:", deals if isinstance(deals, dict) else f"{len(deals)} items")

Trimmed offers response: a real 0.0 price (illustrative)

{
  "success": true,
  "data": {
    "buyBox": {"totalPrice": 0.0, "sellerId": null},
    "offers": []
  }
}

Example run (illustrative data)

{'asin': 'B0CL61F39H', 'price': 444.98, 'seller': 'Amazon', 'offers': 2}
deals: 2 items

How many attempts and what does it cost in credits?

Three attempts covers the real case: the Lambda already retries a parse exception once on its own side before it ever answers, so a 502 reaching your client has usually already survived one internal retry and failed again. A fourth or fifth client-side attempt on top of that mostly pays for the same dead page again. Budget one credit per attempt - a batch that hits a bad page on offers, retries twice more and still fails has spent three credits for zero data, which is the real cost of not capping attempts.

Bottom line: on /amazon-product-offers, /amazon-bestsellers and /amazon-deals, a 502 or 503 is the signal to retry, a real 0.0 price or empty list is the signal to use the data, and three attempts is enough because the Lambda has already retried once on its own. See the 429 and Retry-After guide for the rest of the status codes and the Python quickstart for get_with_retry itself.