A vendor in ILLUMA is more than a name and a phone number — it is a supplier record with its own connections, data feeds, product links and review queue. This article explains how those pieces fit together, so that every other vendor article has somewhere to start.
Vendors live under Purchasing → Vendors in the sidebar. Purchasing is a top-level section of its own — not a page inside Inventory — and it holds exactly two entries: Vendors and Purchase Orders.
The pieces, in one place
| Piece | What it is | Where you manage it |
|---|---|---|
| Vendor | The supplier record — name, code, type, status, terms, contacts, drop ship settings | Vendors list → the vendor’s page |
| Connection | An endpoint we reach the vendor at (an SFTP host, a username, a password) | Vendor page → Integration tab → Connections |
| Feed | One stream of data from the vendor — their catalog, or their stock levels | Vendor page → Integration tab → Products / Inventory |
| Vendor product (alias) | The permanent link between one vendor part number and one of your products, plus that vendor’s cost | Vendor page → Products tab, and each product’s own vendor sources |
| Proposal | A staged decision from a catalog run, waiting for your yes or no | Vendor page → Review (Catalog review) |
The order matters. A connection is how we reach them; a feed is what flows over it; an alias is what the flow produces; a proposal is the gate between the two.
📷 Screenshot: The Vendors list page showing the four stat cards (Active Vendors, Drop Ship Enabled, Pending Setup, Open POs) above the vendor table with Type, Status and Drop Ship columns. (placeholder — replace with
/docs-images/vendors/vendors-overview-vendor-list.png)
The vendor record
Every vendor has a name, a short vendor code, a type and a status.
| Field | Options |
|---|---|
| Vendor Type | Distributor, Manufacturer, Wholesaler, Dropshipper, 3PL Warehouse |
| Status | Active, Pending Setup, On Hold, Inactive |
| Capabilities | Supplier, Drop Ship Enabled, Manufacturer (any combination) |
The capability checkboxes are not cosmetic. Drop Ship Enabled is what unlocks the Drop Ship tab, where lead time, drop ship fee, blind drop ship and packing slip settings live.
The vendor page is organised into tabs:
- Overview — name, code, type, status, website, capabilities, primary contact, account number, payment terms, credit limit, minimum order, performance figures and internal notes.
- Contacts — as many named contacts as you need, each optionally flagged Primary, Receives POs, Billing or Technical, and tagged with a department (Sales, Support, Accounting, Shipping, Technical).
- Products — every product currently sourced from this vendor, with your SKU, their SKU, the cost, and Preferred / Dropship tags.
- Drop Ship — operational settings for drop ship orders: lead time, drop ship fee, blind drop ship, include packing slip.
- Storefront Fulfillment — what shoppers see on product pages for this vendor’s items: home delivery, warehouse pickup, and the vendor’s warehouse network.
- Integration — how purchase orders go out to the vendor, and how their data comes in. This is where connections and feeds live.
- Purchase Orders — a placeholder on the vendor page today; POs are managed under Purchasing → Purchase Orders.
To create one from scratch, see Adding a Vendor.
Connections — how we reach them
A connection is one endpoint the vendor exposes, with the credentials to use it. You enter it once and every feed that runs over it shares it, so a password rotation is a single edit rather than one per feed.
A connection carries a label, a transport, a host, a port, a username and a password. The password is stored encrypted and is never displayed again — when you edit a connection, leaving the password blank keeps the current one.
ℹ️ Note: SFTP is the only transport that runs today. FTPS, API and EDI transports appear in the interface as planned, not available.
Add a second connection when the vendor genuinely uses separate endpoints. When a vendor has more than one, the + Add Feed dialog lists them individually so you attach the feed to the right host rather than whichever one happened to be first.
A connection cannot be deleted while feeds still reference it — delete those feeds first. That is deliberate: nothing gets orphaned pointing at credentials that no longer exist.
Full detail, including port and directory conventions: Vendor Connections.
Feeds — what flows
A feed is one stream of data. Feeds are grouped on the Integration tab by what data they carry, not by how the file arrives.
| Family | Direction | Classic EDI equivalent | What it does |
|---|---|---|---|
| Products (catalog) | Vendor → you | 832 — price/sales catalog | Item master: part numbers, descriptions, UPCs, cost, drop ship cost, MSRP, MAP, weight, images, category groups |
| Inventory | Vendor → you | 846 — inventory advice | Stock quantities per vendor warehouse |
| Purchase orders | You → vendor | 850 — purchase order | Sends a PO to the vendor. Configured under PO Submission Method on the same tab |
The first two are feeds in the strict sense — they have connections, schedules and review queues. The third travels the other way and is configured separately as a PO Submission Method, whose full behaviour is covered in Sending Purchase Orders.
Three of that dropdown’s options actually deliver a purchase order today:
| PO Submission Method | What happens when you send a PO |
|---|---|
| None (Manual) | A plain HTML purchase order email goes to the vendor’s drop ship email address. This is a working delivery path, not a gap — but it is the only one with no address field of its own on this tab, so the drop ship address is set by ILLUMA support rather than on this screen |
| An HTML email (or a PDF attachment, your choice of format) to the vendor’s Submission Email | |
| Freshdesk Ticketing | A Freshdesk ticket with the PO attached, the subject line routing it to the vendor’s queue |
EDI, API, FTP/SFTP and Vendor Portal appear in the same dropdown labelled not available yet, and are unpickable unless a vendor is already set to one. A PO for a vendor on one of those fails with an explicit error and stays in your queue — deliberately, because a silent downgrade to email would tell you the PO went out by EDI when the vendor’s system never received it.
⚠️ Warning: The PO Submission Method setting is about sending orders to the vendor. Pulling catalog and inventory files from them is a completely separate thing, configured under Products, Inventory and Connections on the same tab.
A vendor can have as many feeds as it has files
There is no one-feed-per-family limit. A single vendor can hold an item-master product feed and a second product feed that carries nothing but long-form copy, and a third that carries only MAP pricing, and more than one inventory feed — each with its own connection, schedule, filename pattern and column map.
That is the normal shape for real distributors. Ace ships an Article file (the item master) and a separate Romance file whose only payload is product copy keyed to the same item number; other vendors ship a product sheet and an independent MAP price sheet dated weeks apart. Each is a product feed — same importer, same matching, same review queue — that enriches products the master feed already created.
ℹ️ Note: Never split a supplier into two vendor records just to hold a second file. Two vendor records mean two sets of aliases, two costs and two PO paths for one supplier. Add a second feed instead.
Enrichment-style feeds have their own article: Enrichment Feeds.
How a feed’s files arrive
Each feed has a delivery method, chosen when you click + Add Feed:
- Spreadsheet upload — you upload an Excel or CSV file by hand. No connection needed. Offered for product feeds. See Spreadsheet Uploads.
- SFTP / FTP server — an automated pull on a schedule, over one of the vendor’s connections.
An SFTP feed asks for a directory, an optional archive directory (checked as a fallback if the vendor moves files after pickup), a filename pattern, a delimiter (comma, pipe, tab or semicolon) and a poll interval — 15 minutes, hourly, every 6 hours, every 12 hours, or daily. An upload feed has none of those; there is no endpoint to poll, so it runs when you send it a file.
Feeds are always created switched off
Creating a feed is configuration; running it is a separate, deliberate act. A new feed’s save button even says so: Create Feed (stays off until enabled).
Beyond that, a feed cannot be enabled until it has produced a run summary. Until then the toggle is locked and reads Analyze first (product feeds) or Dry run first (inventory feeds). And enabling only arms the schedule — it does not import immediately. A feed that has never run will not auto-run on being switched on; the first scheduled check lands one poll interval out. Use Run now if you want it sooner.
📷 Screenshot: The Integration tab with the Products panel, Inventory panel and Connections panel visible, one feed row in each. (placeholder — replace with
/docs-images/vendors/vendors-overview-integration-tab.png)
Feed setup in depth: Product Feeds and Inventory Feeds.
The mental model, end to end
Here is what actually happens between a file landing and a product existing.
- A file arrives — either the scheduled SFTP check finds a new file in the directory, or you upload a spreadsheet from the feed’s Upload files button.
- A run is queued — the file is staged and an import job is created. A queued run is claimed by the worker on its next cycle, so give it a few minutes; a large catalog takes longer still.
- The file is analyzed — rows are read, filtered, matched against your catalog by the feed’s matching strategy, and every decision is written down.
- Decisions are staged as proposals — for a product feed, nothing new reaches your catalog. Matches, ambiguities and would-be new products all land in the review queue.
- You review — approve what’s right, reject what isn’t.
- You apply — Apply N matches to catalog writes the aliases and routing for matched products; Create N approved runs a background job that mints the new products.
- Content lands — descriptions, identifiers, images, categories and (only if you allow it) title and price are written under the feed’s update rules.
⚠️ Warning: Step 4 has one exception worth knowing. A catalog run stages everything new, but it also refreshes products this vendor is already linked to — their vendor cost, and their content under the feed’s update rules. The row action even says so: stages new items for review and updates products you already match.
An inventory feed skips the whole review stage. It has no proposals: a live run writes stock levels immediately, which is why its confirmation says this one writes and why the safe first step there is a Dry run.
A run’s stat grid always reports that run’s numbers, never vendor-wide totals — so a copy-only enrichment feed shows the handful of rows it touched rather than the item-master feed’s tens of thousands.
📷 Screenshot: A product feed row after a run, showing the stat grid — matched, created, need review, flagged, not carried, filtered out — with the “Review N to review →” button. (placeholder — replace with
/docs-images/vendors/vendors-overview-feed-run-summary.png)
Proposals and the review queue
The Catalog review screen is where a run’s staged decisions get resolved. Its tabs are the proposal’s status:
| Tab | Meaning |
|---|---|
| To approve | A single confident match. The importer’s opinion, not a decision |
| Needs a decision | Split into Pick a match (several of your products matched — you choose) and New products (nothing matched, so this would create a SKU) |
| Flagged | A would-be new product held back because its brand looks wrong — no brand found, a bare number, or a set/season name rather than a maker |
| Approved | You said yes; waiting to be applied or created |
| Applied | Written to the catalog |
| Rejected | You said no — or the feed auto-excluded it (row filter, blacklisted SKU, blacklisted brand) |
Each row shows the vendor’s side (part number, description, UPC, MPN, brand), their money (cost, drop ship cost, MSRP) and what it would match to. For an ambiguous row, each candidate is shown with its own cost, because a pairing that looks right by name and wrong by price is exactly the one worth catching.
Two chips are worth recognising:
- no content — the vendor’s current file no longer carries this row (or your row filter excludes it). Applying links the vendor and routing but brings no description, image or category.
- ⚑ flag reason — why a new product was held instead of created.
Because an onboarding run can stage tens of thousands of rows, the queue is built for bulk: search, stackable filters (brand, vendor SKU, UPC, MPN, cost, drop-ship cost, MSRP, has/no content), per-row Approve and Reject, multi-select, whole-tab approve/reject, and a Gmail-style Select all N matching that acts on the entire filtered set across pages rather than just the visible page.
💡 Tip: Reject is how you opt rows out permanently. The create job takes the whole un-rejected queue unless you tell it to use only your handpicked approvals — so rejecting the junk once is what keeps the next run clean.
📷 Screenshot: The Catalog review page with the status tabs and their counts, the Pick a match / New products sub-filters, and one ambiguous row showing two candidate products with their costs. (placeholder — replace with
/docs-images/vendors/vendors-overview-review-queue.png)
Working the queue row by row: The Review Queue.
The alias — one vendor part number, one product
When a proposal is applied, the result is a vendor product row: the permanent link between the vendor’s part number and your product. This is the piece everything else depends on. It is not the vendor record — the vendor record is the supplier itself; the alias is one part-number pairing beneath it.
| What it holds | Why it matters |
|---|---|
| Vendor SKU, vendor name, vendor UPC | The identity that later inventory files resolve against |
| Cost, drop ship cost | What you pay. Drop ship cost is kept separate because vendors often charge more to ship direct, and the PO path prefers it for a drop ship order |
| List price, MAP price | The vendor’s MSRP and minimum advertised price |
| Cost updated at | When the cost actually changed, not when the feed last ran |
| Vendor stock quantity, stock status, stock updated at | Filled by the inventory feed |
| Preferred, priority, drop ship eligible, lead time, minimum order quantity, active, discontinued | Sourcing preferences you control |
Three rules follow from this:
- A product can have several vendors. Sourcing lives on the alias, one row per vendor–product pair, which is what makes multi-sourcing possible at all.
- One alias per vendor per product. If a vendor renumbers a part, or two of their part numbers share a UPC, the second one is surfaced for a human instead of overwriting the first.
- A feed never writes your product’s cost price. Vendor cost lives on the alias. Your margin reporting reads it from there, so a nightly feed can’t silently restate history.
Aliases are usually created by applying a review, but you can also add one by hand from the vendor’s Products tab or a product’s own vendor sources — that is the manual path for a supplier who sends you nothing at all.
Stocked versus drop ship
This is the setting that most often explains “the feed ran, it says rows applied, and the storefront still shows nothing.”
A product feed has a Fulfillment setting that decides what applying a match does to the product’s drop ship configuration:
| Mode | Effect |
|---|---|
| Fallback (default) | You fulfil from your own shelf until it runs out, then the vendor does. The safest choice for a distributor you buy from occasionally |
| Always drop ship | The vendor ships every order for these products. Use it when you never hold the stock |
| Leave alone | Applying only records the cost and part number and touches nothing else |
⚠️ Warning: Vendor stock only counts toward what you can sell when the product is drop ship or drop-ship fallback. Choose Leave alone 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.
Applying a review also stamps the vendor as the product’s drop ship vendor, and fills the product’s primary vendor field when it is blank — never overwriting a supplier you already recorded.
When an inventory feed runs, the vendor’s quantities are projected as derived availability at the location you mapped their warehouse code to. That stock belongs to the vendor, not to you: it never passes through inventory adjustments, the ledger, FIFO layers or bins. Rows resolve strictly by the alias — a vendor SKU with no alias yet is reported as an unknown SKU, never guessed at and never auto-created. There is also a Full snapshot option for vendors whose file lists everything they carry, so an item that disappears from the file is treated as out of stock at the vendor rather than left at its last known number.
The vendor’s categories
A product feed can also carry the vendor’s own category hierarchy. A run brings their whole tree in — it never files anything on its own. You then map each of their groups to one of your categories on the vendor’s Category mapping screen (reachable from the feed row’s ⋯ menu), with a Suggest matches button to do the obvious ones for you, and a Skip action for groups you never want imported. Products created under a mapped group are filed into the category it points at.
The mapping screen in detail: Vendor Categories.
What a feed will not do to you
Some of the platform’s most deliberate behaviour is about restraint:
- Your retail price and your titles are yours. Both default to Never change it in the feed’s update rules. Descriptions, identifiers and images default to Only fill it in if mine is blank.
- Nothing is created unless you ask. Creating products from unmatched vendor items is off until you turn it on, and even then a suspect brand is flagged for a human rather than minted.
- Filters fail loudly. A rule naming a column the file does not have excludes everything, on purpose — a typo shows up as an empty import instead of quietly importing what you meant to exclude.
- Skip lists are visible. Vendor part numbers and brands you never want are listed on the feed itself, and rows they drop are labelled as such in the Rejected tab.
- Existing photos survive. Image updates only ever touch the image that vendor supplied; photos you added stay, and stay primary.
When something does not behave as described here, start at Vendor Troubleshooting.
Next
Set up your first vendor from Purchasing → Vendors → Add Vendor — see Adding a Vendor — then add a connection and a product feed on its Integration tab and run it once before enabling it. Stock levels come next, with Inventory Feeds; ordering from the vendor is covered in Sending Purchase Orders.
For the catalog side of what feeds produce, see Products, Categories and Brands. For loading a one-off spreadsheet that has nothing to do with a vendor, see Bulk Import.