Connector
A connector is a ready-made, reusable software component that links two specific systems through their interfaces (APIs) and automates the data exchange between them. In an ERP context, a connector couples the ERP with a shop, marketplace, payment provider, shipping service or accounting system, without having to build the integration from scratch.
A connector is a ready-made, reusable software component that links two specific systems through their interfaces and automates the data exchange between them. Instead of building an integration individually, you reach for an existing connection that is tailored to exactly one pair of systems – such as "ERP to Shopware", "ERP to Amazon" or "ERP to DATEV". The connector knows how both sides work: it is familiar with the addresses and data formats of the respective interfaces and translates between them, so that orders, items, stock levels or documents flow from one system into the other without manual re-keying.
To picture it, a connector is like a perfectly fitting adapter plug: it sits between two devices that on their own would not fit together, and makes sure that power – here: data – still flows cleanly. In the ERP world, connectors are the standard way to couple an inventory management or ERP system to the rest of the system landscape, without setting up a separate development project for every connection. They are therefore a central building block that lets multichannel retailers run their processes end to end and without media breaks.
At a glance
- Connector = ready-made, reusable connection between two specific systems
- Uses the APIs of both sides in the background and translates between their data formats
- Links the ERP with a shop, marketplace, payment provider, shipping service or accounting system
- Saves custom development: configure instead of build
- Needs maintenance when the connected systems or their APIs change
How a connector works
Technically, a connector builds on the interfaces (APIs) of the two systems it links. On one side it retrieves data or writes it – such as new orders from a shop – and hands it over in a suitable form to the other side, for example as an order in the ERP. In between, it does the actual translation work: it converts data formats, maps fields to one another and applies rules so that both systems understand the same information in the same way. A user notices none of this – they simply see the order appear in the ERP as if by itself.
Components of a connector
A connector typically consists of three elements: the link to the source API, the link to the target API and the logic in between. That logic includes the mapping of fields (field mapping), transformation rules for differing formats – such as date, currency or tax details – as well as a control layer that governs when and in which direction synchronisation happens. Many connectors additionally include error handling: if a transfer fails, it is logged and retried later, instead of silently losing data.
Mapping and synchronisation direction
The core of every connector is the field mapping – the agreement about which field on one side corresponds to which field on the other. The customer field of the shop must match the customer master data of the ERP, the item number the item master data. Just as important is the direction: some data runs only one way (orders from the shop into the ERP), other data both ways (stock is maintained in the ERP and mirrored back into the shop). A cleanly defined stock synchronisation thereby prevents overselling across multiple channels.
Connector, API and middleware: the distinction
Connector, API, interface and middleware are often mentioned in the same breath, but they mean different things. An API is the technical docking point that a system offers – the building block on which a connection can be set up in the first place. A connector, by contrast, is the finished connection itself: it uses the APIs of both sides and bundles mapping, rules and workflow into a configurable package. Put simply: the API provides the socket, the connector is the matching cable including the adapter.
A connector differs from middleware in scope. Middleware is an overarching mediation layer that centrally brings together many systems, buffers data and orchestrates workflows; an iPaaS platform is the cloud variant of it. Connectors are often the individual connection modules within such a platform – each connector links one system, the middleware coordinates the whole. In smaller setups, however, a connector also stands on its own, as a direct point-to-point connection between exactly two systems.
Why connectors matter: the benefits
The central advantage of a connector is that an integration does not have to be reinvented every time. Because the connection for a specific pair of systems already exists and is in widespread use, it can usually be configured rather than programmed: enter the credentials, check the mapping, start the synchronisation. This significantly lowers costs and project time and makes integrations attainable even for smaller retailers who do not have their own development team.
On top of that comes reliability: an established connector is maintained by its provider and adapted to changes in the connected systems. If a marketplace changes its API, the provider updates the connector – the retailer does not have to rebuild anything themselves. This creates a robust data hub around the ERP: orders come in automatically, stock stays synchronised across channels, payment statuses and tracking numbers flow back, documents move into accounting. It is precisely this end-to-end flow that is the prerequisite for scaling in e-commerce without a growing staffing effort.
The connector within the ERP system
In the ERP world, connectors are the usual way to link the central system with its periphery. Many ERP providers maintain an app or marketplace area with ready-made connectors to common shops, marketplaces, payment and shipping service providers. For the retailer this means: they select the suitable connector, enter the credentials and define which objects – items, stock, orders, customers, documents – are exchanged in which direction.
Ready-made connector or custom integration
Not every constellation is covered by a standard connector. For widely used systems there are usually ready-made connections; for niche software or heavily customised processes, a custom integration via the API is required. The rule of thumb: wherever a maintained standard connector exists, it is almost always the cheaper and more robust choice. Only when requirements go beyond that – special fields, particular workflows, exotic target systems – is a bespoke integration worthwhile. When choosing an ERP, the number and quality of available connectors is therefore an important criterion.
What matters in practice
A connector is not a set-and-forget affair that works forever once configured. Because it sits between two changing systems, it needs maintenance: if one side updates its API or the retailer changes their mapping, the connector has to follow suit. It is therefore important who owns and updates the connector – the ERP provider, a third-party vendor or a service partner – and how quickly they respond to changes.
Also relevant in practice are the limits of the connected systems, such as rate limits that cap the number of requests per period, as well as idempotent processing, so that the same order is not created twice on a retry. In the DACH region, the link to accounting takes on particular importance: connectors to DATEV or BMD must hand over documents so that the account assignment, tax keys and audit-proof archiving are correct. Faulty mappings quickly stand out here to the tax advisor or during a tax audit – a reason to test financial connectors especially carefully.
Example
Example: a connector between shop and ERP
A retailer of outdoor equipment runs a Shopware shop and keeps stock, orders and invoices in the ERP. Instead of reconciling both systems by hand, they activate the ready-made Shopware connector of their ERP provider. After entering the credentials and checking the field mapping – item number, prices, customer data – the exchange runs automatically: every shop order appears as an order in the ERP, and stock is reduced after a sale and mirrored back into the shop.
When the retailer additionally starts selling via Amazon, they add a second connector. Now both channels run through the same ERP as the central hub; the stock synchronisation prevents an item that is only available once from being sold twice. Because both connectors are maintained by the provider, the retailer does not have to intervene when the platforms change their APIs – they benefit from the updates without any development work of their own.
Frequently asked questions
Related services
Questions about Connector in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.