CSV Headers Gone Wrong, Assets Rejected Instantly: Column-Count Rules Across Three Major Stock Platforms and Automated Fixes

A Weekend Lesson: The Header Row Kills Your Batch Before Review Even Starts

Last March, the author prepared 60 JPGs to submit to Adobe Stock. Using a hand-built CSV, he hit submit and received a rejection in under a minute. It wasn't a content review rejection or a quality issue — the files never made it that far. The parser got stuck on the header row and sent the whole batch back. He fixed the header and resubmitted, only to be rejected again over a different column issue. That's when he stopped guessing and nailed the header down in code.

This reveals a seriously underrated fact: before a human reviewer ever opens your files, a machine has already completed the first round of screening. That round is expensive — you get almost no useful feedback and end up endlessly debugging a spreadsheet.

CSV header errors causing upload failures

Parsers Before People: The Hard Column-Count Rules of Three Major Platforms

Adobe Stock, Vecteezy, and Dreamstime all run a machine check before human review. The check is mechanical: first validate column count and column order, then validate individual assets. Get the column count wrong and what comes back is a metadata error, not a content review result.

The three platforms each require different column counts, with no room for compromise:

Adobe Stock: 5 columns. Filename, title, keywords, category, license statement.
Vecteezy: 4 columns. Filename, title, keywords, category.
Dreamstime: 15 columns. The widest of the three, and where hand-built CSVs most often collapse — miss one empty column and every column after it shifts.

The original author says he tried all three combinations: Adobe's 5-column header doesn't work on Vecteezy, and Dreamstime's 15 columns can't accommodate a 5-column row either.

The trap is that these headers look similar enough that your brain auto-fills the missing parts. You think you're editing a single field when the whole row structure has already gone out of alignment.

Metadata error is a class of technical rejection returned by asset platforms at the upload stage, unrelated to content quality. It's typically triggered when the CSV structure doesn't conform to platform specs, such as mismatched column counts, misspelled column names, misaligned column order, or invalid field formats (e.g., date formats or inconsistent delimiters). Unlike human-review rejections, metadata errors often return only a generic error code or message without pinpointing which row or column is the problem, making debugging costly. More importantly, some platforms count repeated metadata-error uploads as failure records, which may affect your contributor rating. Understand this and the right strategy becomes clear: generate and validate the CSV structure with a script before submitting, rather than trial-and-error after submission based on vague errors.

Why Hand-Editing CSVs Is Doomed

Building a spreadsheet a few times feels safe. By the fortieth time, things start breaking. The failure modes are all mundane: a trailing comma creating a ghost 16th column; a comma pasted into the keywords field instead of the platform's required delimiter; a filename extension typo pointing to a file that doesn't exist. Each one sends the whole batch back, and some platforms count repeated failed uploads against your account record — before any human sees your work.

So the author wrote make_metadata.py. It takes a directory of files and a platform argument and outputs exactly the header that platform requires — no more, no less:

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

The script depends only on the Python standard library — nothing to install. Titles default to the filename converted to title case, fine for a first draft, but you should replace them with real titles and keywords before submitting by passing them in with --titles titles.json.

CSV's implicit structural fragility is the root cause of why hand editing goes wrong. CSV has no type system; columns are separated only by commas, and commas can also appear inside field content (like a keywords list). When a field contains a comma, the standard practice is to wrap the whole field in double quotes, but spreadsheet software may change its quoting strategy on export, or a user pasting manually may introduce an unescaped comma, causing the parser to split one row into multiple columns. A trailing comma creates an empty column at the end of the row, adding one extra column. These errors are hard to spot in a spreadsheet because the cells look normal, but the structure is already misaligned once exported as plain text. Therefore, any CSV destined for machine parsing should be generated by code and validated with a read-back through a parser before submission.

The Second Automation Trap: Duplicate Uploads

Once the CSV is fixed, the next machine-rejection risk comes from you — running the same batch twice. The author did this early on: the upload script was rerun, and the same filenames got uploaded again. Duplicate submissions are one of the fastest ways to get your account flagged; no platform wants a contributor submitting the same asset twice.

The solution is dumb but effective: a ledger. upload_tracker.py records what's already been published in plain text:

python upload_tracker.py pending items.txt   # show what's not yet done
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status

Check pending before every batch upload. Upload only files not in the ledger; skip the ones that are. Again, standard library only — two scripts, zero dependencies, eliminating the two most time-consuming failure categories.

An upload tracker is a lightweight state-management approach for recording which files have been submitted and which haven't. Its core value is idempotency: no matter how many times the upload script reruns, the tracker prevents the same file from being resubmitted. In implementation, the tracker can be a plain text file with one published filename per line, paired with simple subcommands (pending/done/status) for querying and updating. Compared with a database, a plain-text tracker needs no extra dependencies, is easy to version-control, and can be inspected directly in a text editor — suitable for individual contributors and small pipelines. The key habit: run a pending query before every upload and upload only files not in the tracker; write the done record immediately after a successful upload to avoid inconsistent state from mid-process failures.

The Underestimated Engineering Ratio: Creativity Is Only a Third

In the parent project that produced 39 finished pieces and roughly 856MB of output, the pipeline code for handling metadata, tracking, and packaging was about 19,000 lines. That ratio isn't a coincidence. The creative part is one prompt away, while the part that gets you rejected is a header row — one that silently rejects you before any reviewer opens your file.

One more thing worth mentioning: none of this needs a big machine. The entire pipeline, including image generation and packaging, runs on 1 vCPU, 2GB of RAM, and no GPU. The habits that keep it running are plain: one process at a time, calling gc.collect() after each asset, and measuring peak RSS with resource.getrusage rather than averages. If the metadata step needs more than 2GB of memory, you've over-engineered it — generating a 5-column CSV barely uses any resources.

Advice to My Past Self

Write the header once, in code, separated by platform. Never hand-edit a CSV meant for submission. Track every upload with a ledger so reruns can't cause duplicate publishing. And always keep your research notes — the author once deleted a research folder to "clean up," only to need its sources a month later for a new product line, and regretted it deeply.

These lessons are now packaged as scripts: a metadata builder, an upload tracker, a Markdown-to-PDF tool, and a packaging script that zips products and renders 1280×720 covers and 600×600 thumbnails. If you're about to submit your first batch of assets, fix the header first — everything else can wait a day.

The core idea transfers to any platform-based upload scenario: whenever a workflow does machine validation before human review, metadata format takes priority over content quality. Hard-coding format rules into your code and managing state with a ledger is a faster path to efficiency than increasing creative output.

One-line Summary

Asset platform machine parsers run before human review, and CSV header errors kill an entire batch of uploads outright.

Paragraph Summary

When the author submitted 60 JPGs to Adobe Stock, a hand-built CSV header error got them rejected instantly, revealing an underrated fact: machine parsers complete the first screening round before human review, and wrong column counts or order return a metadata error directly. Adobe Stock needs 5 columns, Vecteezy needs 4, and Dreamstime needs 15 — mutually incompatible, and hand editing easily misaligns entire rows through trailing commas or missing empty columns. So the author wrote zero-dependency Python scripts to generate exact platform-specific headers and a plain-text ledger to track uploaded files and avoid duplicate submissions. In a project with 39 finished pieces, metadata handling and packaging code ran about 19,000 lines, with creativity accounting for only about a third of the work, and the entire pipeline ran on 1 vCPU, 2GB of RAM, and no GPU. The core conclusion: whenever a workflow does machine validation before human review, metadata format takes priority over content quality.