eBay

Pushing stock to eBay without burning your daily allowance

eBay rations API calls by the day and accepts four products per stock call. Using all four is the difference between a catalogue that syncs and one that stops at lunchtime.

Your eBay stock updates keep failing with "exceeded usage limit". Thousands of errors, no obvious cause, and no way to tell whether your listings are showing the right quantities right now.

eBay’s stock API has two properties that most sync tools ignore until they collide with them. It accepts up to four products in a single revise call, and it allows a fixed number of calls per day across your whole account.

Send one product per call and a three thousand product catalogue costs three thousand calls. Send four, and the same catalogue costs about seven hundred and fifty. Against a measured daily allowance of five thousand calls, one of those numbers fits comfortably and the other competes with everything else your account needs to do.

What running out actually looks like

Not an outage. eBay simply starts refusing, and each refusal is recorded as a failed stock update. The visible symptom is thousands of sync errors all reading the same thing, which reads like a broken integration rather than a budget that was spent by mid-morning.

It is worse than it first appears, because the calls are refused in the order they were attempted. The listings at the end of the alphabet never get their update at all, and they are the ones quietly showing yesterday’s quantities.

Four per call, and stop when the budget is gone

Qwikr batches to the full four, and — more importantly — it recognises a quota refusal and stops, rather than spending the remainder of the run being told no. A run that stops early reports how many were not attempted, so you know the difference between “this failed” and “this has not happened yet”.

Re-running the next day picks up where it left off. That is a normal outcome to plan around rather than an error to investigate.

Two eBay APIs that cannot see each other

Worth knowing, because it produces genuinely baffling numbers. eBay has an older Trading API and a newer Inventory API, and a listing created through one is not visible to the other. Counting your listings through the wrong one can be out by a factor of thirty.

The practical consequence is that the bulk stock call cannot revise an Inventory API listing at all. Including one spends a call purely to be told so — which is precisely the waste the batching exists to avoid — so those listings are skipped rather than attempted.

A button, not a terminal

Pushing your own catalogue’s stock to eBay is something a merchant should be able to do without asking anybody for shell access. It runs from a screen, it can be capped so you can try ten before committing to three thousand, and the outcome is written where you can read it back later — how many were sent, accepted, rejected and not attempted, and when.

The near-miss worth telling you about

The first version of this bulk push read the wrong database column for the quantity. The column did not exist, so every quantity came back empty, and every empty quantity became zero. Running it would have set an entire eBay catalogue to zero stock and de-listed the lot.

It was caught before it ran, and the fix was structural rather than a corrected line: the bulk path and the single-product path now build their payload through the same code, so there is one implementation to get right. There is also a test that asserts the number reaching eBay is the stock actually held — the test whose absence let it through.

That is the standard everything touching a marketplace is held to here, because marketplace APIs have no undo.

Stop reconciling stock by hand

One catalogue, six channels, one stock figure that stays right.