The ten-products-a-day wall

Twenty-one products ready. Files built, covers rendered, descriptions written, prices set. One command to publish the lot.

Twelve went up. The rest came back with:

Sorry, you can only create 10 products per day.

Returned with HTTP 200, incidentally, in the body of a response that otherwise looks like success. If you are checking status codes rather than reading the payload, you will record nine failures as nine wins.

What the wall actually is

Gumroad allows ten new products per day, per account. There is a second, shorter limit of roughly ten product creations per minute that returns a 429, and that one is easy — you sleep and retry. The daily cap is different in kind. No amount of waiting inside your script gets past it. Your run is over.

Two details cost me a day each.

The day boundary is not your day. I am in Dubai, four hours ahead of UTC. My publish job ran at 00:13 local time, which felt like a brand new day and was still the previous afternoon as far as the counter was concerned. Four products, four rejections. If you are east of London, your reset is in the small hours; mine is 04:00. Find yours before you schedule anything.

Failed attempts and deleted products may still count. I have not tested this exhaustively, but the safe assumption is that the counter tracks creation attempts, not surviving products. Do not plan to use the tenth slot as a retry.

Why this is not really a rate-limit problem

My first instinct was to write a scheduler: queue everything, publish ten a day, walk away. I did build that. But sitting with the failure for a day made me notice the plan underneath it was wrong anyway.

A catalogue dumped in one evening gets one launch. Twenty-one products going live at once produce a single announcement, a single wave of attention, and twenty products nobody looks at. Ten a day for three days is not a workaround for a limit — it is three launches, and the second and third are informed by what the first taught you about which titles get clicked.

You do not know your ordering until something sells. With everything live at once you learn nothing about sequence. Publishing in batches forces you to answer "which ten first?" — and that question is worth more than the day it costs you. My first ten should have been the ten with the clearest search demand, not the ten that happened to be alphabetically early in a JSON file.

The limit is a floor under quality. Ten products is about as many as one person can write a real description for in a day. When I hit the wall I had nine descriptions that were noticeably thinner than the first twelve. The cap stopped me shipping them.

What I do now

• Publish in batches of ten, deliberately ordered. Highest search demand first, cheapest impulse product in the first batch to seed reviews.
• Read the response body, not the status code. A 200 that says "sorry" is a failure. My publisher now treats any body containing an apology as an error, logs it in full, and re-queues the product rather than marking it done.
• Schedule against the reset, in UTC. Retry jobs fire at 00:10 UTC, not at midnight local.
• Keep the queue in the catalogue file, not in the script. Each product carries its own published-URL field. Anything without one is still pending, so a re-run is naturally idempotent and I can stop worrying about double-publishing.
• Never treat "all uploaded" as "launched". Uploading is the cheap half.

The wider version of this

Every platform you build on has a limit like this somewhere — listings per day, API calls per hour, emails per campaign, uploads per channel. You will find each one by hitting it, always on the evening you had set aside to finish.

The useful habit is not memorising the limits. It is building the pipeline so that hitting one is boring: the failure is logged in words, the queue survives the crash, the retry is scheduled, and tomorrow's run picks up exactly where tonight's stopped. Then the wall costs you a day instead of a weekend.

Mine cost a day. The nine descriptions I rewrote in that day were better than the ones I would have shipped.