Double-Posting Gets Stock Accounts Flagged: upload_tracker.py Prevents It

I learned about double-posting the way most people do: the hard way. I had a batch of 40 assets, ran my upload script, watched it stall at file 23, killed it, and ran it again. The script, being dumb and honest, started from file 1. By the time I noticed, 23 files had been submitted twice in one afternoon. The account got restricted within the week. Nobody sent me a warning first. That was the moment upload_tracker.py got written, not because tracking is clever, but because forgetting is expensive.

Here is what actually works, in order.

The Rule the Platforms Never Explain Twice

Stock platforms treat a duplicate submission as spam, not a mistake. It does not matter that the duplicate was your own file with the same metadata. Two identical entries from one seller in a short window looks like an automated flood, and the account-level response is the blunt one: flag, throttle, or suspend. The fastest way to trip that is a re-run. Any batch script that restarts from zero after a crash guarantees it.

So the fix is not a smarter uploader. It is a ledger that sits between you and the uploader and refuses to let the same filename go out twice, ever, regardless of how many times the process dies and restarts. upload_tracker.py is that ledger, and it is deliberately boring. Standard library only, no install, no database. You can look at its state in a text file and understand it in ten seconds.

pending, done, status: Three Commands That End Repeat Submissions

The whole workflow is three commands:

python upload_tracker.py pending items.txt   # shows what is NOT done yet
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status

pending reads your list of items and prints only the ones not yet in the ledger. That is the output you feed the uploader, not the raw file list. If the process crashes halfway, you re-run pending and it hands you exactly the remainder. Nothing already marked done comes back. This is the entire protection mechanism, and it is why the script uses only the standard library: a ledger you cannot run because a package failed to install is not a ledger.

Mark items done as each one succeeds, not after the batch. A batch-level mark is what let my 23 duplicates happen in the first place.

The Metadata Side Is the Other Half of Compliance

Flagging is not only about duplicates. All three channels I write for reject a wrong CSV header instantly, and a rejection storm on a fresh account reads the same as spam. make_metadata.py builds the exact header each platform demands and nothing else:

python make_metadata.py ./my-assets --platform adobe      --out metadata.csv   --ext .jpg
python make_metadata.py ./my-assets --platform vecteezy   --out vecteezy.csv   --ext .jpg
python make_metadata.py ./my-assets --platform dreamstime --out dreamstime.csv --ext .jpg

That is Adobe's 5-column format, Vecteezy's 4-column format, and Dreamstime's 15-column format, matched exactly. One honest warning: without --titles titles.json, the script title-cases the filename and calls that your title. It is fine for a dry run and not fine for submission. Replace the titles before you send anything. A title that is obviously a filename is its own soft spam signal.

Keep the Batch Small and the Structure Fixed

Two habits from the parent project cut the duplicate risk further. First, keep batches modest. This pipeline packaged 39 finished products, 856 MB of output, and it ran on 1 vCPU with 2 GB of RAM by processing one file per subprocess and calling gc.collect() after each asset. A 40-file batch that takes minutes is easier to verify than a 400-file batch you walk away from.

Second, use one fixed folder layout, because catalogue drift is how filenames collide:

project/
  assets/
  output/
  packs/
  research/
  scripts/

Every done entry refers to a stable, unique filename in assets/. If you rename files between runs, the ledger cannot recognize them, and recognition is the whole point. Keep research/ permanently. The scrape logs and notes behind the rules these scripts enforce are 300+ pages of raw material, and deleting them to clean up is a mistake I made once and will not repeat.

What I Actually Sell, and Why

The ledger and the metadata builder are two of four scripts in the kit, and they are the two that map directly onto account risk. The other two, md2pdf.py for turning a Markdown doc into a styled PDF and pack_product.py for zipping a product with a 1280x720 cover and 600x600 thumbnail, handle the packaging step. Together they turn one prompt engine into 39 finished products with no framework and no cloud account, and with only two third-party packages across the set: Pillow and reportlab, used only where images and PDFs are actually rendered.

I packaged the version I use, with the platform rules it enforces, as the compliance metadata kit. If your failure mode looks like mine, a crash and a re-run and a flagged account, the ledger alone is worth the download.

Get compliance metadata kit

Building digital products? Free guides & kits for digital product sellers.