The Supplier Adapter Pattern: Map Once, Apply Forever

Every tool that handles supplier data faces the same fundamental problem: suppliers don't send data in your format. They send it in their format. And every supplier's format is different.

The question isn't how to transform the data — that's straightforward. The question is: how do you avoid doing the same transformation work next month?

That's the problem the Supplier Adapter pattern solves.

What Is a Supplier Adapter?

A Supplier Adapter is a saved configuration that captures everything FeedPrep learned about a specific supplier's data format. It includes:

• Column mappings: colour_name → color, Gewicht → weight
• Value translations: meadow → green, Eiche → oak
• Unit conversions: grams → kilograms, inches → millimeters
• Normalization rules: date format standardization, decimal separator handling, text casing
• Ignored columns: columns you've explicitly chosen to skip

Think of it as a recipe card for transforming Supplier X's data into your standard format. Once written, the recipe works every time.

How It Gets Built

You don't write an adapter from scratch. It builds itself as you work through a supplier's first feed.

Here's the process:

1. Upload the file. FeedPrep parses it and detects columns, data types, and patterns.
2. Map columns. The system suggests mappings based on column names. You confirm, correct, or skip each one. Every decision is saved.
3. Review values. For select/multiselect attributes (like color or material), the system shows you source values that need mapping. You translate them to your canonical values. Saved.
4. Set normalization rules. Units, date formats, text casing. Configure once per supplier.
5. Process and export. The feed runs through all your rules. You review the output.

At the end of this process, everything you did is captured in a Supplier Adapter. You didn't have to write it — it wrote itself from your actions.

What Happens Next Time

Next month, the same supplier sends an updated file. You upload it. FeedPrep recognizes the supplier and auto-applies the adapter.

Columns are mapped. Values are translated. Units are converted. All automatically.

What you see is the output — the normalized data, ready for review. Your job shifts from "map everything from scratch" to "check the results and approve."

This is why the second feed takes 5 minutes instead of 2 hours. The adapter did the work.

When Things Change

Suppliers change their formats. A column gets renamed. A new attribute appears. An old one disappears. This is where most manual processes break — the person who knew the old format has to figure out what changed and adapt.

FeedPrep's feed monitoring catches this. When a feed's structure doesn't match the existing adapter, you get a clear alert:

Column renamed: "colour" → "product_color"
New column: "eco_rating" (not in adapter)
Missing column: "care_info" (expected by adapter)

You update the adapter — map the new column, adjust the renamed one — and from then on, the updated adapter handles future feeds. It's a 10-minute update, not a 2-hour rebuild.

Why This Matters More Than AI

AI-powered data cleaning gets a lot of attention. And AI has its place — it's useful for suggesting column mappings and value translations, especially for new suppliers.

But the real value isn't in AI. It's in deterministic rules that you've validated. When you tell FeedPrep that meadow means green for Supplier X, that rule applies with 100% confidence every time. No probabilistic guessing. No hallucinations. No variation between runs.

AI helps with the first feed. Supplier Adapters handle every feed after that. The adapter pattern is where the compounding value lives.

The Compounding Effect

Here's what the timeline looks like for a team onboarding suppliers over six months:

• Month 1: 5 suppliers onboarded. 5 adapters built. Time spent: similar to manual (you're teaching the system).
• Month 2: Same 5 suppliers send updates. Adapters auto-apply. Time spent: 90% less than manual.
• Month 3: 3 new suppliers added. 3 new adapters built. 5 existing feeds processed automatically.
• Month 6: 15 adapters. Monthly updates from all 15 suppliers take a total of 30 minutes. All the knowledge accumulated over 6 months is active and working.

This is the learning curve we talk about. It's not a marketing abstraction — it's literally how the system works. Every adapter you build reduces your future workload permanently.

What Makes This Different From a Script

You could achieve similar automation with custom scripts. Many teams do. But scripts have three problems that adapters solve:

1. Scripts require a developer. Adapters are built by the person who understands the data, using a visual interface. No code required.
2. Scripts are invisible. When something breaks, someone has to read the code to understand what was expected. Adapters are self-documenting — every mapping and rule is visible and editable.
3. Scripts are fragile. They work until they don't, then they crash. Adapters fail gracefully, flagging what changed instead of throwing an error.

Try It

The best way to understand the Supplier Adapter pattern is to build one. Start a free trial, upload a real supplier file, and map it. Then upload a second file from the same supplier. Watch the adapter do its thing.

That moment — when the second feed processes in minutes instead of hours — is when the pattern clicks.