Integration platform for retail
Integration without losing control
Interfaces for retail — built in the browser, executed durably, billed by capacity instead of by record.
ConFlowIO is not an ERP, not a PIM and not a shop system. It connects what you already have — with a ready-made commerce data model and a price that follows capacity rather than the individual record.
Download the whitepaperDeutschEnglish
Vendor and operations in Germany. Self-hosted on request.
- 4shop systems natively connected
- 14shared commerce data models instead of one mapping per shop
- 22bundled building-block groups, from files to message queues
- 0records metered: you pay for capacity, not consumption
The problem
Why interfaces have become the bottleneck
Ten years ago: one shop, one inventory system, one interface. Today: a shop, one or two marketplaces, a PIM, an ERP, a shipping system, an accounting package — and suppliers in double digits.
Connections grow quadratically
The number of people maintaining them does not grow at all.
What emerges is familiar to every grown retail IT estate: a script on a server nobody wants to touch; a cron job whose author left the company. That works until something changes — and in retail, something always changes.
- Somebody's first job in the morning is checking whether the night's import completed.
- A new supplier means “we'll manage that next quarter”.
- Nobody can say without looking which articles the last run actually wrote.
- Changing one pricing rule means carrying it into several imports by hand.
The partial success is what costs
40,000 of 120,000 articles updated, then the connection drops.
The catalogue is now inconsistent but not visibly broken: prices are right for part of the range, stock levels for another. An evening like that regularly costs more than a year of running the interface.
- work out where the run stopped
- decide whether a second one can safely run
- correct the damage the first one did
What you get out of it
Peace of mind, security, insight
Three things decide, in daily operation, whether a landscape of interfaces makes work or keeps quiet.
Peace of mind
It runs. And when something goes wrong, it does not cost you an evening.
- Failed steps retry themselves
- A failed run is continued rather than started over
- A second attempt creates nothing twice
- A new supplier is a field mapping, not a project
Security
Your credentials and your data stay where they belong.
- Stored encrypted, removed from every log line
- Vendor and operations in Germany, self-hosted on request
- Workspaces separated fail-closed, roles and an audit log
- Bulk deletion in the shop with a safety limit and a dry run
Insight
You see what is happening — while it happens, not afterwards.
- Live logs per step, while the process is working
- Every run traceable on its own: which building block, how long, what was written
- Processes are visible in the editor instead of buried in a script
- Knowledge about an interface stays inside the company
The interface
The process lives in the editor, not in a script
Whoever takes over an interface can see it — instead of reconstructing it from a cron job written three years ago by somebody who has since left.
What the process does is in the picture
A process is a canvas with building blocks on it. Every building block shows its settings on the card itself; what it hands to the next one is written on the connection.
Runs can be started from a particular building block — for testing, without reading the whole catalogue again.
A new supplier is a field mapping
On the left the outputs of the upstream steps, in the middle the source and target schema and the rule per field — from a field, from an expression or as a fixed value — and on the right a trial run for this step alone.
This is the work a generic platform demands again for every shop system. Here it is done once, against the Commerce Bundle.
A catalogue import as it actually looks
The catalogue is read and checked; what passes the check is mapped onto the shop product, normalised by a macro and written to Shopware 6.
What fails is written to a file and reported to purchasing.
The argument
Five sentences that matter
Of the five vendor categories on the market, not one offers the ready-made commerce data model, durable execution, costs measured by capacity rather than by record, and a choice of operating model — together.
The operating model has to fit the company, not the other way round.
NIS2 is in force, and where a data centre stands does not replace the jurisdiction the vendor is under. Vendor and operations are in Germany; the platform is delivered managed and runs in your own house on request — the same platform, the same feature set.
Connecting to e-commerce is a data model, not a connector.
Shopware, Shopify and Adobe Commerce hold fundamentally different views of what a product is. Anyone who does not resolve that into one shared model builds every mapping as many times as they have shops.
Durability decides the cost of running it, not the technology.
A half-written catalogue is more expensive than one not written at all.
A per-operation meter penalises exactly the processes that create value.
Anyone paying per record thinks twice about an hourly stock reconciliation.
Openness beats connector counts.
No vendor has the connector for your one special supplier format. What matters is how quickly it comes into being — and whether you are allowed to build it yourself.
Commerce Bundle
One commerce data model instead of one mapping per shop
Fourteen bundled data models that every shop connection speaks. You map your source data onto them once — which target system is written at the end is then a matter of the last building block in the process.
Reaching a shop system is not the work. The work is that every shop system holds a different idea of what a product is.
Sources
- Supplier catalogue (BMEcat)
- ERP export (CSV, Excel)
- PIM over REST
- Database
Commerce Bundle — 14 data models, one mapping
Target systems
- Shopware 6
- Shopware 5
- Shopify
- Adobe Commerce
- Tradebyte TB.One
The fourteen data models in detail
- Product
- SKU, product number, EAN/GTIN, manufacturer number, name, description, short description, manufacturer, brand, categories, net and gross price, RRP, purchase price, currency, tax rate, stock, delivery time, unit of measure, packaging and base-price unit, weight and dimensions
- Category
- Category tree with parent-child relationships
- Manufacturer
- Manufacturer master data
- Property group
- Filter and variant characteristics, group level
- Property
- Filter and variant characteristics, value level
- Variant
- The variations of a product
- Price
- Tiered and customer-group-dependent prices
- Tax rate
- Tax rates and how they are assigned
- Sales channel
- The channels you sell through
- Customer group
- Price and visibility groups
- Media
- Images and files with their assignment
- Download
- Digital attachments to a product
- Product reference
- Accessories, cross-selling, relationships
- Product visibility
- Which product appears in which channel
The catalogue for Tradebyte TB.One comes out of the same model: in the process the difference is a different target building block, not a second mapping.
Why a shared model
Four shop systems, four answers to the same question
| System | How an article is recognised | Where the price sits | Where the stock sits |
|---|---|---|---|
| Shopware 6 | a 32-character internal identifier; the article number has to be mapped onto it | on the product, as a price list per currency | on the product |
| Shopware 5 | directly by the article number | on the article detail | on the article detail |
| Shopify | no business key — only an internal identifier and a URL handle | on the variant only | per location, through an interface of its own |
| Adobe Commerce | directly by the SKU | on the product, extra fields in a separate list | in the extension attributes |
Integrations
What ConFlowIO connects to
The feature set as it ships today. What is listed here exists in the product — when a connection is added or dropped, this list is brought into line in the same round.
Shop systems
Writing products, categories and master data, reading data back, writing product images along with them, and a free interface call — on all four.
Shopware 6batch writing, mediation between article number and internal identifier, indexing can be switched off for the duration of an import, bulk deletion with a safety limit and a dry run
Shopware 5articles directly by their article number, no lookup; writes per record rather than in batches
Shopifythe current GraphQL interface; price, barcode and weight on the variant; stock per location, and the location is stated rather than guessed
Adobe CommerceREST, identical for Magento Open Source; products by SKU; custom and extension attributes assembled from a single field table
Marketplaces
Eight building blocks for the catalogue side and the order side, with four data models of their own for order, order line, order message and article stock.
Tradebyte TB.Onehand over catalogue and stock, read and complete orders, report status, read order messages, fetch an order document, free request
Supplier catalogues and file formats
Reading and writing, the same building block for both directions.
BMEcatincluding the category tree
CSV and fixed-width records
XML, JSON and Excel (XLSX)
File transport and images
Where the files sit, and what happens to the images inside them.
FTP, SFTP, S3-compatible object storage, local directoriespacking and unpacking archives
- Image processingsize, format, preparation for the shop
Databases
Reading and writing, with large reads processed page by page.
MySQL and MariaDB
PostgreSQL
Microsoft SQL Server
MongoDB
Message queues
As a trigger and as a target.
RabbitMQ
Apache Kafka
Interfaces and email
Outward and inward.
Outgoing HTTP/RESTincluding a REST building block that reads page by page
- Incoming webhookssecured per building block by key, token, basic authentication or signature check — an unknown scheme is refused rather than let through
SMTP sending and IMAP mailbox watching
Data preparation
Eleven building blocks between source and target.
- Change detectionpasses on only the records that actually changed out of a full catalogue — in practice the difference between a nightly full reconciliation and an hourly one
- Cast, split, filter, validatemerge, sort, remove duplicates, aggregate, collect
- Codeyour own logic directly in the process, for the one-off case that does not justify a plugin
Triggers
Six ways to start a process. Overlapping runs are a choice: skip, queue, cancel the running one, or allow them in parallel.
- Manualstarted from the interface, also from a particular building block onwards — for testing and fault-finding
- Schedulerecurring by a time rule, or once at a point in time
- Webhookan address of its own per building block, secured
- Eventone process triggers another, across system boundaries too
- Message queuean incoming message from RabbitMQ or Kafka
- Mailboxan incoming email over IMAP, for supplier files sent as attachments
Reuse and extension come on top: macros as sub-processes that appear in any number of processes as a single building block; your own data models, including ones derived from the bundled set; and extensibility in three stages — code in the process, your own plugin loaded while the system is running, or an addition to the bundled building blocks.
In detail
What ships as a ready-made building block, per shop system
| Building block | Shopware 6 | Shopware 5 | Shopify | Adobe Commerce |
|---|---|---|---|---|
| Write products, categories and master data | Bundled building block | Bundled building block | Bundled building block | Bundled building block |
| Read data | Bundled building block | Bundled building block | Bundled building block | Bundled building block |
| Write product images | Bundled building block | Bundled building block | Bundled building block | Bundled building block |
| Free interface call | Bundled building block | Bundled building block | Bundled building block | Bundled building block |
| Media library as its own building block | Bundled building block | No building block of its own | No building block of its own | No building block of its own |
| Upload arbitrary files | Bundled building block | No building block of its own | No building block of its own | No building block of its own |
| Bulk deletion with a safety limit | Bundled building block | No building block of its own | No building block of its own | No building block of its own |
| Control indexing | Bundled building block | No building block of its own | No building block of its own | No building block of its own |
A dash does not mean the shop cannot do it: the free interface call reaches every endpoint, only without the groundwork and the safeguards of a ready-made building block. Product images end up in all four shops. Shopware 6 is the most built-out connection because it is the most often asked for — a matter of project experience, not of architecture.
Execution
A run is continued, not started over
Durability here is a property of the product, not a retry loop. The difference only shows at real catalogue volumes — and then it shows every day.
Failed steps retry automatically
up to three times with a growing interval, configurable per building block. Completed steps are never executed again.
Large reads are processed page by page
each page is a step of its own. An import that breaks off at page 90 repeats page 90.
A server restart does not end a run
another worker takes over at the point last reached.
A failed execution can be continued
The continued run skips every branch that finished the first time and takes over the files already downloaded and read. A record already dealt with is recognised by its content, not by its position.
Every building block states whether it may take part
one that may not prevents continuation and is named.
Cancelling is cooperative
the step ends in an orderly way instead of being cut off mid-write.
An approval building block holds a run
until somebody approves or rejects. No decision by the deadline counts as a rejection.
A catalogue import that broke off at record 6,342 does not write the first 6,341 a second time.
Insight
You see what is happening — while it happens, not afterwards
That is the difference between “the import has been running for two hours, no idea where it is” and a dependable statement.
The overview of an installation
How many runs, how many of them succeeded, how long they take and how busy the workers are — each for the selected period. Every bar leads into the individual run and its log.
Every run is individually traceable: which building blocks ran, how long they took, what each step logged. Logs stream live into the interface while the process is working.
Counters sit beside the log — “4,312 of 12,000 products” at a glance, while the run is working. You set the log detail per process, from “everything” to “errors only”, and raise or lower it for a single run when you start it by hand. Credentials are stripped from every log line, including messages returned by a remote system.
In practice
Three processes, as they actually look
Supplier catalogue into the shop
40 suppliers, each with their own format and their own rhythm.
- Trigger: a schedule, or a file arriving over SFTP
- Read: BMEcat, CSV or Excel, per supplier
- Macro: pricing logic and checks, the same for all of them
- Write: Shopware 6, in batches
A new supplier is connected in a morning rather than in a sprint. A change to the pricing logic applies at once to all forty imports.
Stock and prices every hour
The ERP holds the stock; three sales channels have to follow.
- Trigger: hourly
- Read: the ERP database, page by page
- Change detection
- Channels: Shopware 6, Shopify, marketplaces over TB.One
Of 200,000 articles a few hundred change every hour; only those are written. The hourly rhythm stays a business decision rather than a question of cost.
Orders back into the ERP
Orders should reach the ERP without delay and without a polling loop.
- Trigger: the shop's webhook, secured per building block
- Check: signature, structure, plausibility
- Transform: addresses, line items, payment methods
- Write: the ERP over REST or its database
No order is lost and none is entered by hand. And if something does jam, the overview says which order it is.
Security
Where your credentials live and who can see them
An integration platform is the place where the credentials to every other system live. That makes it the most interesting system in the house from a security point of view — and the one most superficially examined in a selection process.
In exactly one place, encrypted
Processes and connections never store the password itself, only a reference to it; the plaintext is substituted only when a run starts. Reading a stored credential back demands your own account password again — a valid session alone is not enough. Every credential shows when it was last displayed in plaintext, and by whom.
Several workspaces in one installation are separated fail-closed: a query without a workspace is refused rather than answered more broadly. Roles apply per workspace and are enforced at the interface, not merely by hidden menu items. On top of that: a second factor through time-based one-time passwords or passkeys, a lockout after failed sign-in attempts per account, and an audit log of administrative actions.
Operating
Two operating models, one platform
The e-commerce specialists offer their own cloud and nothing else; the EDI houses offer self-hosting without a commerce data model. ConFlowIO is the platform where the hosting question and the catalogue question have the same answer — and where changing operating model later is not a migration project.
Standard
Managed
You sign in and build the first process.
Installation, updates, backups and monitoring are ConFlowIO's.
- Vendor and operations in Germany
- No limit on processes, building blocks or users
- The same feature set as self-hosted
In your own house
On request — the same software, not a reduced offshoot.
Two documented routes: Docker Compose for one or a few servers, Kubernetes as manifests for GitOps operation.
- PostgreSQL or SQLite as the database
- Multi-tenancy within one installation
- Changing operating model later is not a migration project
Pricing logic
You are billed for capacity, not for consumption
The model counts no records, runs or operations. It does not cap the number of connectors, processes, workers or users. And it unlocks no features you pay extra for — the feature set is the same for everyone.
Staying honest is part of it: more volume needs more machine at ConFlowIO too, and the price rises with it. The difference is in how it rises — in a few predictable steps rather than with every single record. Within a step, one more reconciliation costs nothing extra.
| Model | What drives the price | Behaviour as you grow | Predictability |
|---|---|---|---|
| Per operation (automation tools) | number of records processed | rises proportionally | low |
| Connector + volume (e-commerce iPaaS) | connected systems and operations | jumps in steps | medium |
| Enterprise licence (enterprise iPaaS) | contract negotiation | rises at renewal | medium |
| In-house development | person-days | rises with every interface | low |
| ConFlowIO | capacity provided | rises in a few steps | high |
Concrete prices are not on this page while there is no published price list. Let us work through your most expensive planned process together. When a term runs out, a transition period of 14 days follows in which everything keeps running unchanged; 30 days beforehand the interface shows the same notice as a precaution.
Where we sit
The market, factually
This describes what follows from a business model — not that a vendor is bad. Three gaps no category closes: self-hosting and a commerce data model together, predictable costs at high volumes, and durability as a property of the product rather than as a retry loop.
| Category | Self-hosting | Pricing logic | Catalogue volumes | Shop data model |
|---|---|---|---|---|
| Enterprise iPaaS | partly / hybrid | subscription + volume | good | generic |
| Automation tools | partly, with a licence limit | per operation | weak | generic |
| E-commerce specialists | no | connectors + operations | good | present |
| EDI houses | yes | subscription / licence | very good | document-oriented |
| In-house development | yes | staff costs | it depends | built yourself |
| ConFlowIO | your choice: managed or in your own house | capacity instead of an operation counter | processed page by page | bundled |
A snapshot, as of September 2026. Every statement about a third-party vendor goes back to a publicly available source; the sources are listed in the appendix of the whitepaper. Trade and product names belong to their respective owners.
Before you decide
The questions you would ask anyway
Ask them of every vendor you look at. The answers differ more than the product pages do.
Do you offer both operating models?
Yes. The managed platform is the standard; the same platform runs in your own data centre on request — the same feature set, not a reduced offshoot.
Which jurisdiction are you under?
Vendor and operations are in Germany. Where a data centre stands and which jurisdiction the vendor is under are two questions; NIS2 asks both.
What drives the price?
The capacity provided. No records, no connectors, no users.
What happens to the price if we go from daily to hourly?
Within the capacity you already have, nothing.
Is there a bundled commerce data model?
Yes — the Commerce Bundle, with fourteen data models that every shop connection speaks.
How does a second run recognise products it already created?
By the business key of the target system in question. That is a different key per shop — the table above names all four.
What happens to a run interrupted by a server restart at record 80,000 of 120,000?
Another worker takes over at the point last reached. If the run fails for good, it can be continued rather than started over.
Are logs visible while a run is going?
Yes, live and per step. Credentials are removed from them — including from messages a remote system sends back.
How is an accidental bulk deletion guarded against?
By a safety limit — a maximum permitted share of the stock — and a dry run.
Can we build our own building blocks?
Yes, in three stages: a code building block in the process for one-off logic, your own plugin loaded into an isolated environment while the system is running, or an addition to the bundled building blocks.
Is there a usage restriction for agencies?
No. Multi-tenancy, roles per workspace, and no limit on processes or users.
Next step
We are glad to show ConFlowIO on your own data.
Bring a real slice of your catalogue. The difference this page is about shows at real volumes — not at five sample records.
info@conflowio.com