One row per product, one column with an image URL. GridShot processes the file as a batch job, creates the products and hands them to the same generation pipeline the shop integrations use.
CSV, XLSX, XLS and XLSM are accepted, up to 20 MB and 10,000 rows per file. Delimiters are detected automatically, so a semicolon-separated export out of a German ERP works as it comes.
GridShot detects the image URL column and the common product columns from their headers. You see the detected mapping and a row preview before anything runs, and you can point it at a different column if the guess is wrong.
The file becomes one job processed by a worker pool with live progress. Rows are read, images fetched and products created while you watch the counter — and a single bad row fails on its own instead of taking the run down with it.
From here it is the normal studio flow: each run produces a grid of 16–25 variations in about 5–15 minutes, and you deliver only the shots you want as final images.
Exactly one column is mandatory: a URL pointing at a product image. Everything else is optional and only makes the result better. Headers are matched case-insensitively, and several common names are recognised for each field:
| Field | Recognised headers | What it does |
|---|---|---|
| Image URL (required) | url, image_url, image, product_url, image_link, photo_url … | The product photo GridShot works from. Rows without a usable http(s) URL are skipped and reported. |
| Product name | name, product_name, title, product_title | Becomes the product name. Without it, products are harder to tell apart in your library. |
| Brand | brand, brand_name, manufacturer, vendor | Stored on the product — useful when several labels run through one workspace. |
| SKU | sku, product_sku, product_id, id | Stays attached to the product so finished images map back to your catalog. |
| Price | price, product_price, cost | Stored as the source price alongside its currency, for reference only. |
| Description | description, product_description, desc | Kept as product context you can read and edit. |
| Anything else | any other column | Preserved with the import, so the original row stays traceable even where a value does not map to a product field. |
This is the part worth understanding before you build the file. Each row creates one product from one image. If you have front, back and detail shots of the same garment, listing them as three rows produces three separate products — not one product with three views.
For multiple views of a single item, use the product URL route instead: GridShot reads the product page, resolves its gallery and creates one product whose photos become perspectives. Those perspectives are what the generator uses as fit references, so the extra step is worth it for hero products. For breadth — one good image each across a large catalog — CSV is the right tool.
Name, brand, description, SKU, price and currency are written onto the product, together with the source shop, the product link and the original product ID, so every generated image stays traceable to the row it came from.
Category and colour work differently. Those columns are read and kept with the import, but the values that end up on the product come from GridShot’s own image analysis, which looks at the actual photo rather than trusting the spreadsheet. In practice that is the more reliable source — exported category trees rarely match how a garment needs to be treated in generation.
GridShot renders garment length and fit from curated values — brand truth that overrides what the AI infers from the photo and enters generation as a non-negotiable fit instruction. A “Length” or “Fit” column in your export is exactly the kind of data those values should come from, because you maintain it for your customers rather than guessing at it.
Today those columns are not mapped: curated length and fit are set per product inside GridShot. On a large import that means a pass through your hero products rather than all of them — the AI-derived values carry the rest, with a softer influence on the prompt.
Batch imports fail in boring ways. Here is how this one behaves:
The import itself is free. You pay for the images you publish:
A worked example: a 200-product seasonal drop with three published images each comes to 600 published images — roughly $600, plus the compute for the runs behind them. Importing all 200 rows costs nothing at all, and the $10 starting credit covers your first ten images, so you can validate the output on real garments before committing to the batch.
See full pricingAll three paths feed the same generation pipeline. They differ only in how products get in.
Connect the store read-only over OAuth to browse your catalog, then bring products in by product URL or through this batch route.
Shopify integrationThe WooCommerce connection uses read-only REST API keys and works the same way from product selection onward.
WooCommerce integrationOne: a column containing an image URL. Product name, brand, SKU, price and description are optional and are picked up automatically when their headers use a common name. Everything else in the file is preserved with the import.
XLSX, XLS and XLSM work just as well as CSV, up to 20 MB and 10,000 rows. Delimiters are detected automatically, so semicolon-separated exports need no cleanup, and quoted fields containing commas are handled correctly.
Not through CSV — each row becomes its own product with one image. For front, back and detail views of the same garment, import that product by its product URL instead: GridShot resolves the gallery into perspectives of one product, and those perspectives are what the generator uses as fit references.
Rows without a usable URL are skipped and reported. Downloads that fail transiently are retried with backoff; a row that still fails is marked failed and the batch continues. Only a run that fails consistently stops itself — so you find out early rather than at row nine thousand.
Yes, and it is the sensible order. Import twenty rows, generate for two or three of them and judge the output on your own garments. The $10 starting credit covers that, and the mapping you validate on twenty rows is the same one that runs on ten thousand.
No. The batch route is the fastest way in for anyone with more products than patience, whatever the size of the catalog — a spreadsheet of forty items is as valid as one of four thousand. Larger operations tend to add the API on top rather than replace this.