eBay rate limits are a fact of life for active resellers. The moment your store picks up real velocity, you start bumping into 429 errors: eBay's way of telling you to slow down. Until now, that meant failed syncs, dropped actions, and Sentry alerts that were noise masking real problems. That changes today.
What a 429 Actually Means
Most error handling treats a 429 like any other failure. Retry with backoff, hope for the best, surface the error to the user if it keeps happening.
The problem: a 429 is not a failure. When eBay sends a 429 response, it includes a Retry-After header that says exactly how many seconds to wait before the request will succeed. It is not guessing. It is not a suggestion. It is a precise instruction from eBay's rate-limiter telling you the window is open again at a specific moment.
We were ignoring that signal and treating the request as failed. That meant real costs: actions that didn't complete, sync rows that appeared as misses, Sentry noise that made it harder to find actual bugs.
What We Shipped
Intelligent 429 retry handling that honors eBay's Retry-After header, built directly into the HTTP layer of our marketplace adapter.
The change adds a dedicated rate-limit retry handler to the eBay SDK's axios instance. Here is what it does:
- When eBay returns a 429, the handler reads the
Retry-Afterresponse header - It waits exactly that long (capped at 30 seconds to prevent runaway delays)
- If no
Retry-Afterheader is present, it uses a 1s / 4s exponential fallback - It retries the request in place, transparently, before any caller code sees a failure
- Each request gets a budget of 2 retry attempts maximum
The result: rate-limit blips are now completely invisible to the rest of the system. Your listings sync. Your actions complete. The only thing that changes is you stop seeing 429s in your activity log.
Why In-Place Retry Matters
An important design decision here: the retry happens at the HTTP layer, not at the higher-level retry machinery we already have (the dispatch retry cron, the daily sync cadence).
This was deliberate. Our higher-level retries are designed for transient network errors and downstream failures. If we let 429s bubble up to those layers, we'd be double-retrying write operations, which could multiply marketplace mutations. An eBay listing update retried twice at the job level could fire the same change multiple times.
By catching 429s at the HTTP layer and retrying the exact same call in place, we get reliability without side effects.
Retry-After Parsing
The handler parses two formats eBay might send:
Delta seconds format:
Retry-After: 5Wait exactly 5 seconds, then retry.
HTTP date format:
Retry-After: Thu, 02 Jul 2026 03:00:00 GMTCalculate the difference from now, wait that long.
Both are handled correctly, with a 30-second ceiling so no individual request hangs indefinitely.
Safe Feature Detection
One more detail worth calling out: the retry handler is registered using feature detection against the eBay SDK's axios instance shape.
If a future version of ebay-api changes the internal structure, the handler gracefully degrades to a no-op instead of throwing an error during adapter construction. This protects against a dependency upgrade breaking the adapter entirely.
Before and After
| Scenario | Before | After |
|---|---|---|
| eBay returns 429 with Retry-After: 3 | Request fails, action marked as error | Handler waits 3s, retries, action succeeds |
| eBay returns 429 with no Retry-After | Request fails immediately | Handler waits 1s, then 4s, retries up to 2x |
| 429 persists beyond retry budget | Request fails (same as before) | Request fails (graceful) |
| eBay API version change breaks SDK shape | Adapter construction error | Handler registers as no-op, adapter works normally |
| High-volume listing session hits rate limits | Failed syncs, Sentry noise | Transparent retries, clean activity log |
How This Affects Your Day-to-Day
If your store has moderate to high listing volume, you have probably seen 429-related gaps before without knowing it. A sync that showed fewer updates than expected. An action that appeared to fail and required a manual retry.
Those cases should now resolve themselves automatically.
For lower-volume stores, you are unlikely to notice anything different, which is exactly the point. The change is infrastructure-level: it improves reliability without changing any workflow or UI.
You do not need to do anything. The update is live and applies to all eBay connections.
What This Is Part Of
This release is part of a broader reliability focus on the marketplace adapter layer. Over the past several weeks we shipped proactive re-auth notifications (so you know before your eBay connection goes quiet), Sale Manager's new inventory lens for sold items, and improvements to how the system handles and communicates errors.
The pattern is consistent: the system should handle expected platform behavior gracefully, surface real problems clearly, and stay out of your way when things are working.
eBay rate limits are expected behavior for active stores. Now ListForge handles them the way eBay designed them to be handled.
Technical Notes for the Curious
For those who want to understand the implementation in detail:
The handler lives in packages/marketplace-adapters/src/utils/rate-limit.ts and is registered via registerEbayRateLimitRetry in the eBay adapter constructor. The extractRetryAfterMs utility handles both Retry-After header formats and returns milliseconds for the wait. The spec file (rate-limit.spec.ts) covers delta-seconds parsing, HTTP date parsing, missing header fallback, and the 30-second ceiling.
The handler is deliberately 429-only. Other transient errors (5xx, network timeouts, connection resets) belong to the callers' own retry logic. The distinction matters because those errors carry different signals about whether retrying immediately makes sense.
Try It Out
ListForge is built for resellers who want to move fast without the operational overhead of managing marketplace connections manually. If you are not using it yet, start your free trial at list-forge.ai.
If you are already using ListForge, this update is live. Your next sync will be cleaner.