A product feed is the vendor’s item master — their entire catalog as a file: part numbers, descriptions, barcodes, your cost, MSRP. ILLUMA reads it on a schedule, links each vendor item to the matching product in your catalog, and stages anything it can’t place confidently for your review.
What a product feed does
Every row in the file gets exactly one outcome:
| The row | What happens |
|---|---|
| Matches one product you already have | Staged as a proposed link — approve it and the vendor’s part number is linked to that product, with their cost recorded against it |
| Matches more than one product | Staged for review — only you can pick |
| Matches nothing, and creating is on | Staged as a proposed new product |
| Matches nothing, and creating is off | Counted as “not carried” — the vendor sells it, you don’t |
| Excluded by your import rules | Skipped entirely, as if it were never in the file |
| Already linked from a previous run | The link is refreshed with the vendor’s current cost, and the product picks up any content this feed carries for it |
Two rules govern what a run may touch:
⚠️ Warning: A product feed never writes the cost field your margin reports read. That one is absolute. The vendor’s cost lives on the vendor link (used for purchase orders and drop-ship pricing), not on the product’s cost field. Retail price is a different matter: it is left alone by default, but it is a setting — see Updating products you already have. Retail price is always set on products the feed creates, defaulted from the vendor’s MSRP so the item is sellable — after that it’s yours.
Feeds live on the vendor: go to Purchasing → Vendors → open the vendor → Integration tab → Products.
ℹ️ Note: A vendor can carry as many product feeds as they have files — an item-master file, a separate content or “romance” drop, a MAP or cost sheet that arrives on its own cadence. Each is its own feed row with its own directory, filename pattern, delimiter, column map, filters and schedule. Ace ships an Article file and a Romance file; VSG ships a product sheet and a MAP sheet weeks apart. Don’t split a vendor in two to accommodate a second file — add a second feed. See Enrichment & Content Feeds. The same holds for inventory: more than one inventory feed per vendor is allowed.
📷 Screenshot: The Integration tab of a vendor, showing the Products section with two catalog feed rows (label, Product Catalog badge, SFTP badge, directory + filename pattern, “Checks every hour”) and the Inventory section below it. (placeholder — replace with
/docs-images/vendors/product-feeds-integration-tab.png)
Before you start
A feed needs a connection — the SFTP host, port, username and password, entered once under Connections and shared by every feed that runs over it. See Vendor Connections.
If the vendor emails you a spreadsheet instead of hosting one, choose Spreadsheet upload when you click + Add Feed. Everything below about mapping, matching, filters, brands, titles and review works identically — the only difference is that you send the file by hand instead of the system fetching it, so there’s no directory, delimiter or schedule to configure. See Spreadsheet Uploads.
Where the files are
| Field | What it means |
|---|---|
| Directory (required) | The pickup directory on the vendor’s server, e.g. /outbound. |
| Archive Directory | Checked as a fallback. Many distributors empty the pickup folder after collection — if a poll is missed, the file is recovered from here. |
| Filename Pattern | Shell-style glob matched against file names, e.g. *_Catalog_*.csv. Leave blank to take every file in the directory. |
Both directories are listed on every check, pickup first. A file the feed has already ingested is never picked up twice — it’s tracked by name, and by content, so a vendor re-dropping an identical file costs nothing. When several new files are waiting, they’re processed oldest first so a backlog lands in drop order.
💡 Tip: When a vendor drops several different files into the same directory, the filename pattern is what keeps each feed on its own file. Ace’s item master and its Romance file share a folder; give each feed a pattern narrow enough that it can only ever pick up its own.
File format
| Setting | Detail |
|---|---|
| Delimiter | Comma, Pipe, Tab or Semicolon. One vendor can use different delimiters for different files — Ace ships a pipe-delimited catalog and a comma-delimited inventory file, both named .csv. Check the actual file. |
| Expected Columns | Optional safety check. Any row with a different column count is rejected and listed in the run’s error report. Reading the columns (below) fills this in from the real file. |
| First row is a header | Must stay checked. |
⚠️ Warning: A product feed requires a header row. If First row is a header is unchecked, the run fails immediately with “vendor feeds require a header row” — it has no other way to know which column is which.
ℹ️ Note: A small number of vendors ship a banner line above the header. The importer can discard a fixed number of rows before it reads the header, but there is no control for it in the feed setup form — it is set on the feed by ILLUMA support. If the columns come back as garbage because row 1 is a title line, that’s the fix to ask for.
Files are parsed forgivingly on purpose: a stray quote mark in a description (6" clamp) won’t abort the import, and a byte-order mark or trailing spaces in the header are trimmed automatically.
Identity: how rows find your products
Vendor Part-Number Column is required. It’s the column holding the vendor’s own item number, and it becomes the permanent link between their catalog and yours — every future inventory update and every purchase order resolves through it.
Matching Strategy decides how a row finds an existing product the first time:
| Strategy | How it matches | When to use it |
|---|---|---|
| UPC / barcode | Barcodes on both sides are normalized to a common length before comparing | Strongest, when the vendor supplies UPCs and your products have them |
| Manufacturer part # + brand | Part number matched within a brand — using either the brand name or the brand code, whichever the vendor supplies | Best coverage when UPC data is thin |
| UPC, then manufacturer part # + brand | Tries UPC first, falls back to part # + brand | Best overall when UPC coverage is patchy |
| Vendor’s part # is our SKU | The vendor’s item number is compared against your SKU | Only when your catalog is numbered the vendor’s way |
| Manufacturer part # only | Part number alone, ignoring brand | Risky — part numbers repeat across unrelated brands, so many rows find several products and go to review instead of linking |
A few things worth knowing about matching:
- Barcodes are compared as GTIN-14. Codes shorter than 11 digits, longer than 14, or all zeros are treated as no barcode — they’d match the wrong thing. Eight-digit codes are also refused, because a UPC-E needs expanding rather than padding.
- Part numbers are compared upper-cased with spaces removed. Hyphens and dots are kept: stripping them would merge genuinely different parts.
- Part # + brand only matches when both halves are present. A part number with no brand never falls through to a brand-less match.
- Matching never guesses. Two products for one row is ambiguous, and ambiguous always goes to a human.
- A vendor part number the feed has linked before short-circuits all of this. It goes straight to the existing link, refreshes the cost, and enriches the product — which is exactly what lets a second, content-only feed on the same vendor do useful work on rows the item-master feed already matched.
Column mapping — the full vocabulary
Click Read columns from the vendor and the setup form pulls the header row (and the first data row’s values) straight off the newest matching file, so every column picker becomes a dropdown of the vendor’s real headers with sample values beside them. Vendor headers are case-sensitive and often odd — Manufacturer#, Consumer_Brand — so this is worth doing before anything else.
Only mapped columns are read. Anything you don’t map is ignored, no matter what it contains.
| Map a column to | Shown in the picker as | What it’s used for |
|---|---|---|
vendor_sku |
Vendor Part # (their item number) | Optional here — the part-number column is normally chosen under Identity above |
upc |
UPC / Barcode | Matching; stored on the link; becomes the barcode on products the feed creates, and the gtin an enriching run may fill in |
name |
Product Name | The {name} piece of a created product’s title, and the vendor’s name for the item on the link |
mpn |
Manufacturer Part # | Matching (with brand); the {mpn} piece of a title; the part number on created products, and the manufacturer_part_number an enriching run may fill in |
brand |
Brand name | Brand resolution and matching; the brand on created products (created if it’s new to you) |
brand_code |
Brand code / MFR ID | An alternative match key for vendors who ship a manufacturer ID instead of a brand name |
cost |
Your Cost (stocking) | Your cost from this vendor, recorded on the link — not on the product |
dropship_cost |
Your Cost (drop ship) | The cost when they ship direct. Purchase orders use this first on a drop-ship order and fall back to stocking cost |
msrp |
MSRP / List Price | The vendor’s list price on the link, and the starting retail price on products the feed creates |
map_price |
MAP Price | The advertising floor, on the link and on created products |
weight |
Weight | Weight on created products; part of the identifiers group when you apply a match from the review queue |
image |
Image URL | The picture for products the feed creates |
manufacturer_description |
Manufacturer’s description | The manufacturer’s long-form copy |
vendor_description |
Vendor’s description | The vendor’s own long-form copy |
attributes_text |
Attribute blob (Key: value) | A Product Type: Peg Hook *Brand Name: Rust Oleum *Color: Black style string, parsed into real product attributes instead of dumped into a description |
💡 Tip: Map
dropship_costif the vendor quotes a different price to ship direct. If it’s unmapped, drop-ship purchase orders are priced at the stocking cost and you absorb the difference silently.
📷 Screenshot: The Column Mapping section after “Read columns from the vendor” has run — the green confirmation line showing the filename and column count, and three mapping rows where the left dropdown lists vendor headers with sample values (“Consumer_Brand — SPRAYWAY”) and the right dropdown lists ILLUMA fields. (placeholder — replace with
/docs-images/vendors/product-feeds-column-mapping.png)
Which items to import
Rules under Which items to import decide what enters the import at all. A filtered row behaves as if it were never in the file: not matched, no cost recorded, no category counted, no product. No rules means import everything.
| Condition | Meaning |
|---|---|
| is / is not | Exact value, case-insensitive |
| is one of / is not one of | Comma-separated list, case-insensitive |
| is at most / is at least / is less than / is greater than | Numeric comparison |
| has any value / is blank | Presence check — no value needed |
Rules stack: + Add Rule adds another line, and every rule must pass. They’re ANDed together.
⚠️ Warning: A rule naming a column the file doesn’t have excludes everything — deliberately. A typo shows up as an empty import you’ll notice, rather than quietly importing the rows you meant to exclude. The same applies to a numeric comparison against a column that isn’t numeric.
If a row you’ve now filtered out already had something waiting in your review queue, that entry is closed and marked rejected on the next run. It’s an obsolete promise — left open it would look appliable and apply as an empty shell.
📷 Screenshot: The “Which items to import” rule builder with two stacked rules — a column dropdown showing vendor headers with sample values, the condition dropdown open showing all ten operators, and a value box — plus the “+ Add Rule” button and the warning hint beneath it. (placeholder — replace with
/docs-images/vendors/product-feeds-import-filter-rules.png)
Skip lists
Two operator-managed lists, for junk the vendor won’t fix upstream. One value per line, or comma-separated; both are case-insensitive.
- Skip these vendor part numbers — a hand-fixed item the feed keeps re-breaking.
- Skip these brands — matched against the brand after the brand rules below resolve it. Useful when a “brand” is really a set or season name.
A row hit by either list is dropped exactly like a filtered one, and shows in the review queue’s rejected records with the reason.
Brand source
Most vendors need nothing here — their brand column is fine, and an empty rule list means “use the mapped brand column”.
Some vendors’ brand columns are a junk drawer. Ace puts a 0, a code, or a shelf label in its brand column and hides the real manufacturer inside a Brand Name: label in the description. Brand rules fix that: they run top to bottom, and the first rule that finds a real (non-junk) value wins.
Each rule says look in one field, optionally for a Label: inside it:
| Look in | Reads |
|---|---|
| the Brand column | The column mapped to brand |
| the Description | The column mapped to vendor_description |
| the Attribute blob | The column mapped to attributes_text |
| the Mfr description | The column mapped to manufacturer_description |
| the Product name | The column mapped to name |
| the MPN | The column mapped to mpn |
Leave the label box blank to use the whole field. Fill it in — e.g. Brand Name — and the rule extracts just that one Key: value pair from inside the field. The match is case-insensitive and anchored, so Brand Name can’t accidentally pick up the value of Sub Brand Name.
What counts as “junk” (a junk value skips to the next rule):
- Blank — always, and not configurable.
- All-number values, when you tick that box. This catches
0and zero-padded article numbers. - Any exact value you list, comma-separated and case-insensitive —
0, N/A, TBD.
If every rule comes up junk, the product simply has no brand.
The resolved brand matters in three places at once: it’s half of the part # + brand match key, it’s the {brand} in a created product’s title, and it’s the brand record the product is filed under. That’s why it’s resolved once, up front, before anything else reads the row.
📷 Screenshot: The Brand source section with two rules — Rule 1 reading “the Attribute blob” for “Brand Name”, Rule 2 reading “the Brand column” with a blank label — plus the junk checkboxes below. (placeholder — replace with
/docs-images/vendors/product-feeds-brand-rules.png)
Categories
Name the columns carrying the vendor’s category levels, broadest first, giving each level its code column and its name column. The code is the identity — a distributor’s leaf code is usually only unique within its parent, so the whole path is what identifies a node.
A run brings the vendor’s entire tree in, with a count of items under each node, so you have something real to map against. Discovery is upsert-only: a node you’ve already mapped keeps your decision, and a node that stops appearing in a file is left in place rather than deleted.
ℹ️ Note: A feed run never files a product into a category on its own. It records what the vendor sent; you decide what it means on the Vendor Categories screen. A product gets shelved when you apply it, using the mapping you made.
A level with a missing code column stops the walk — the levels below it are ignored rather than building a tree with a hole in it. Likewise, a row with a department but no group belongs to the department.
Creating new products
Tick Create products for vendor items that don’t match anything to let this feed populate your catalog. Everything in this section only applies to items the feed creates — a product you already have keeps its own title, images and settings.
The creation filter
Separate from the import filter above, and with the same operators. Items that fail the creation filter are still matched and their cost is still recorded — they just never become new products. Use it to take a distributor’s full catalog for pricing and availability while only creating products from the departments you actually sell.
⚠️ Warning: Like the import filter, a rule naming a column the file doesn’t have blocks everything. That’s the safer failure: a filter that quietly stops filtering can dump tens of thousands of items into your catalog.
SKU for new products
| Option | Behaviour |
|---|---|
| Generate from your number series (default) | Your own numbering, from the PROD series under Settings → Number Series. Consistent no matter which vendor an item came from |
| Use the vendor’s part number | Good if you already number your catalog their way — but two vendors using the same scheme will collide |
| Use the manufacturer part number | Part numbers repeat across brands, so expect some to fall back |
Whatever you choose, a value that’s blank or already in use falls back to the number series. That isn’t politeness: a duplicate SKU means orders against the wrong product.
ℹ️ Note: If your
PRODseries isn’t configured, or its starting number sits below SKUs you already use, product creation stops with an error telling you to move the series past your highest SKU.
Title for new products
Vendors ship shelf-tag shorthand in capitals — SPRAY ADHSV 4OZ WHT LIQ — which is not a product title. The template turns it into something that reads like the rest of your catalog.
Tokens: {brand}, {mpn}, {name}. Default: {brand} {mpn} {name} → Qual-Craft 2500 Steel Red Roof Bracket 1 pk.
- A piece the feed didn’t supply drops out cleanly — no gaps, no double spaces.
{brand}and{name}are re-cased out of ALL CAPS. Anything the vendor wrote with any lowercase in it was written deliberately and is left alone.- Acronyms and model codes survive: a word with no vowels (
NGK,MTD) or containing a digit (3M,WD40) is kept as sent. Hyphenated compounds are one word —QUAL-CRAFTbecomesQual-Craft. {mpn}is an identifier and is never re-cased —SX50353/4Gstays exactly that.- If your template includes
{brand}and the vendor already put the brand at the front of the name, it isn’t repeated.
Changed the template after creating products? Use ⋯ → Re-title products on the feed row. It runs in the background and only touches products this vendor created, only where the title actually changes, and never a title you’ve locked.
Images on new products
| Option | Behaviour |
|---|---|
| Link the vendor’s URL (default) | Nothing to download, so imports stay fast. But the image stays theirs — if they move or delete it, your product page breaks with no warning |
| Copy to our CDN | We download the image and serve it ourselves, so the vendor can’t break your pages. Slower — a large catalog can mean gigabytes. Worth switching to once you know you’re keeping this vendor’s products |
| Don’t import images | The image column is ignored; new products arrive without pictures |
With Copy to our CDN, products are linked to the vendor’s URL first and the bytes are moved onto our CDN by a background sweep afterwards, so a slow vendor server never holds up the import. If a particular image can’t be fetched, the product keeps the vendor’s link rather than losing the picture entirely — a broken image URL is never a reason to lose a product.
Fulfillment
What creating a product does to its drop ship setting:
| Option | Behaviour |
|---|---|
| Fallback (default) | Fulfilled from your own shelf until it runs out, then from the vendor. Safest for a distributor you buy from occasionally |
| Always drop ship | The vendor ships every order for these products. Use when you never hold the stock |
| Leave alone | Only the cost and part number are recorded |
⚠️ Warning: Leave alone has a consequence that isn’t obvious: this vendor’s stock only counts toward what you can sell if the product is drop ship or drop-ship fallback. Choose it and the inventory feed will run, report rows applied, and the storefront will still never see a unit. Pick it only when you want the vendor’s catalog data and nothing else.
What a created product looks like
Active, purchasable, inventory-tracked, of type simple, with this vendor as its primary supplier and a URL slug derived from its new title. It carries the manufacturer part number, barcode, weight, both descriptions and the MAP price when the feed supplies them, its brand (created for you if it’s new), and a retail price defaulted from the vendor’s MSRP so it’s sellable straight away. Its cost field is deliberately left alone — cost lives on the vendor link. Reprice it however you like — see Products.
Updating products you already have
When the feed matches a product you already carry, this decides what the vendor may change. Each group is Never change it, Only fill it in if mine is blank, or The vendor’s version wins.
| Group | Covers | Default |
|---|---|---|
| Descriptions | Manufacturer’s and vendor’s long-form copy | Only fill it in if mine is blank |
| Part numbers, barcodes, weight | Manufacturer part number, barcode, weight | Only fill it in if mine is blank |
| Images | Only the image this vendor supplied — photos you added stay, and stay primary | Only fill it in if mine is blank |
| Product title | The product’s title | Never change it |
| Retail price | Retail price and MAP. This is retail, not cost | Never change it |
Where each group actually takes effect:
- Descriptions and the part number / barcode half of identifiers are written by a feed run, on every row that resolves to a product this vendor is already linked to. That is what makes a vendor’s content file — a spec sheet, a marketing copy drop — reach products you already match without you doing anything.
- Weight, images, categories and retail price are written when you apply a match from the review queue.
- Product title is the exception. The setting is there, but no path supplies a title for a product you already have — neither a feed run nor Apply — so today the Product title policy has no effect on matched products. Re-titling is done deliberately with ⋯ → Re-title products, and that only ever touches products this vendor created.
⚠️ Warning: Retail price defaults to Never change it, which is why a product feed leaves your pricing alone out of the box. It is a setting, not a law. Switch it to The vendor’s version wins and applying a match will overwrite your retail price and MAP with the vendor’s MSRP. The genuinely absolute guarantee is the other one: a feed never writes the product’s cost field.
Vendor cost is not governed by any of these — it always updates, and it’s what drop-ship purchase orders are priced from. It’s also only written when it actually changed, so a nightly full file with stable prices costs nothing and “cost last updated” keeps meaning what it says.
💡 Tip: Any single product can be protected on its own page, per aspect — description, identifiers, title, price, image, category. A lock always wins: it downgrades The vendor’s version wins to fill-a-blank-only, because filling a genuine blank takes nothing away from whoever locked it.
Attributes from a mapped attribute blob are written in the same pass as descriptions, so an existing product picks up structured specs it didn’t have.
Review, then apply
A product-feed run proposes; you dispose. Nothing reaches your catalog’s vendor links until you approve it and hit Apply on the review queue. That includes confident single matches — the run’s opinion is still just an opinion. There is no dashboard control that turns review off; every product-feed run stages.
Creating a product is the most consequential thing a feed does: it mints a SKU, may invent a brand you don’t have, and puts an item in your catalog nobody chose to stock. So new items are staged too, and a proposed product whose brand looks wrong is held even harder:
| A new product is flagged when its brand | Example |
|---|---|
| Is missing entirely | — |
| Is a bare number | 0, 0000041258 |
| Starts with a year or season | 2025 Topps, 2024/25 Panini Select |
Flagged items are never auto-created. They wait in their own lane for you to confirm, fix or reject.
Decisions are permanent in the right direction. Once you’ve approved, applied or rejected an item, later runs never re-surface it and never overwrite your decision. Items still waiting are refreshed on each run with the vendor’s current data — a corrected price, a fixed description, a category path that didn’t exist when it was first staged — so you’re never applying stale data believing it’s current.
Running a feed
The order is always: configure → run → read the numbers → work the queue → enable.
- Create the feed — it’s saved switched off, and the button says so: Create Feed (stays off until enabled). Creating a feed never starts it.
- Run it — press Run feed on the feed row. It reads the vendor’s newest matching file and stages every decision for review. Nothing is created in your catalog and no vendor link is written.
- Read the results — the stat grid appears on the feed row when the run finishes.
- Work the review queue — approve and apply. This is where products get created and links get written.
- Enable the feed — the toggle unlocks once a run has produced results. Until then it’s greyed out and reads Analyze first.
ℹ️ Note: A product feed has no Dry run. Its verification step is the run: a product-feed run cannot write to your catalog, so running it is already the safe rehearsal that a dry run would be. Dry run exists only on inventory feeds, which write stock levels directly and therefore need a rehearsal that writes nothing at all.
ℹ️ Note: The toggle stays locked until a run has actually happened. And if you change anything that affects what the import does — directory, mappings, filters, brand rules, gates, titles — the previous run’s numbers are cleared, because they described a different feed. Re-run before enabling.
A queued run is picked up by the worker on its next poll, usually within a few minutes; a large catalog then takes a while to process. The feed row shows a spinner until it finishes.
Other actions live behind ⋯ on the feed row:
| Action | What it does |
|---|---|
| Run again | Re-reads the current file with your current settings. Appears once the feed has run at least once. Safe to repeat — refreshing a pending item is idempotent |
| Fresh re-analyze | Clears everything currently waiting for review (to approve, needs a decision, flagged) and rebuilds it from scratch. Products you’ve already created and applied, and items you’ve rejected, are untouched |
| Edit feed | Everything except the feed type and its connection. Those change which importer runs and which endpoint it runs over — delete and recreate instead |
| Category mapping | The vendor’s discovered tree — see Vendor Categories |
| Re-title products | Background re-title of products this vendor created, from the current template |
| Upload files | Spreadsheet feeds only — send the vendor’s workbook by hand |
| Delete feed | Removes the configuration |
⚠️ Warning: “Writes nothing to your catalog” is precise, not loose. A product-feed run still refreshes vendor costs on links you already have, writes descriptions and part numbers onto products you already match under your update policy, and records the vendor’s category tree. What it cannot do is create a product, create a vendor link, or change a retail price — those all wait for Apply.
Only one job per feed runs at a time. Ask for a second while one is in flight and you’ll be told “A run is already queued for this feed” — two runs computing against a catalog the other is changing would produce numbers neither of them can stand behind.
The schedule
Check For New Files Every: 15 minutes, hour, 6 hours, 12 hours, or day.
- A disabled feed never runs on schedule, however overdue it looks. It only runs when you ask.
- A feed that has never run doesn’t auto-run the moment you enable it. Enabling starts the clock, so the first scheduled run lands one interval later — which leaves you room to run it once and look first.
- When a check finds nothing new, nothing happens; the row says so.
- Each feed on a vendor keeps its own schedule. A nightly item master and a weekly MAP sheet don’t have to share an interval.
Reading the run summary
| Stat | Meaning |
|---|---|
| matched | Rows that resolved to a product you already have — either already linked and refreshed, or staged as a proposed link |
| created | New products from this vendor. Only ever non-zero after you apply from the review queue |
| need review | New products or ambiguous matches — your call |
| flagged | Held because the resolved brand is suspect |
| not carried | The vendor stocks it, you don’t. A count, not a worklist |
| filtered out | Excluded — one tile for your import rules, one for your creation filter |
| vendor categories | Distinct nodes found in their hierarchy |
| failed | Rows that couldn’t be read |
Failed rows get a downloadable report; the row’s Review → link goes straight to the queue.
ℹ️ Note: The stat grid always shows this run’s numbers, never the vendor-wide totals. A content-only feed that creates nothing shows zeros for created even when the item-master feed beside it staged forty thousand. The vendor-wide pending count lives on the Review → button, because a queue really is shared across the vendor’s feeds.
📷 Screenshot: A feed row after a run — the “Last run” badge, row count and relative time, the “Review 1,284 to review →” button, and the stat grid with matched / created / need review / flagged / not carried / filtered out tiles. (placeholder — replace with
/docs-images/vendors/product-feeds-run-summary.png)
Troubleshooting
| What you see | What it usually means |
|---|---|
| “vendor feeds require a header row” | First row is a header is unchecked |
| “feed has no vendor-sku column …” | The part-number column doesn’t match a real header. Read the columns and pick from the list |
| “no file matching … to examine” | The filename pattern doesn’t match anything in either directory — or the directory itself is wrong |
| Everything filtered out, nothing imported | A filter rule names a column that isn’t in the file, or compares a non-numeric column numerically. Both fail closed on purpose |
| Every row goes to review under Manufacturer part # only | Expected. Part numbers repeat across brands — switch to part # + brand |
| Zero matches under UPC | Rows without a usable barcode can’t match under this strategy. Try UPC, then manufacturer part # + brand |
| Columns come back shifted or nonsensical | The file starts with a banner line above the header. Ask ILLUMA support to set the feed to discard it |
| “created” stays at 0 after every run | Correct. A run stages; products are created when you apply from the review queue |
| Titles didn’t change after editing the template | Runs don’t re-title. Use ⋯ → Re-title products — and note it only touches products this vendor created |
| Inventory applies but nothing is sellable | The products’ drop ship setting is Leave alone. Vendor stock only counts when a product is drop ship or drop-ship fallback |
| Run finished with an error | The message is on the feed row; hover for the full text |
| “A run is already queued for this feed” | Another job for this feed is still running. Wait for the spinner to clear |
| A second file from the same vendor is being ignored | Give it its own feed. A vendor can have as many product feeds as they have files — see Enrichment & Content Feeds |
Next
Once the catalog is matched and applied, add the Inventory Feed so vendor stock keeps flowing, and work through the Review Queue to turn proposals into real products. If this vendor also ships content, MAP or cost on separate files, add each as its own feed — see Enrichment & Content Feeds.