APIs for online stores: what they do and what determines integration costs
Connecting your store and ERP: understand how APIs work, which data matters and what affects the cost of a reliable integration.
Quick answer
An API enables controlled data exchange between applications. In e-commerce, it can send an order from the store to an ERP system or return available stock to the store. Reliable operation also requires clear data mapping, rules for changes and error handling. Having an API does not by itself provide a complete store integration.
In this article
- What is the difference between an API, a connector and an interface?
- Which data should your store and ERP exchange?
- Is CSV enough, or do you need an API?
- Standard connector or custom development?
- What do existing integrations show in practice?
- How much does an API integration cost?
- Does an API automatically mean real-time updates?
- What should you test before going live?
- Frequently asked questions
- Sources
“But both systems have an API.” We understand that reasoning. The important question is whether both sides understand the required information in a compatible form. Product identifiers must be unique, a customer price must be assigned to the correct customer, and retrying an order transfer must not create a duplicate order.
What is the difference between an API, a connector and an interface?
An interface is a defined point of interaction between systems. An API specifies how software can use particular data or functions provided by another application. A connector is a specific integration solution that uses these access points to transfer data between particular applications. Definitions: IBM.
For retailers, the practical distinction matters: “API available” does not automatically mean “ERP fully integrated”. The implementation determines which data is transferred, in which direction and under which rules.
Which data should your store and ERP exchange?
The following table is a planning example. Decide which application is the source of truth for each data type in your project; this varies between retailers.
| Data | Typical direction | Agree in advance |
|---|---|---|
| SKUs and master data | ERP or PIM → store | Unique IDs, required fields and how deleted products are handled |
| Images and descriptions | PIM, ERP or store | Which system may overwrite which content? |
| Available stock | Inventory system → store | Reservations, safety stock and update intervals |
| Customer and quantity pricing | ERP → store | Customer assignments, quantity tiers and price validity |
| Orders | Store → ERP | Transfer timing, payment status and duplicate prevention |
| Shipping status and tracking | ERP or shipping software → store | Partial shipments and multiple parcels |
| Returns and refunds | Depends on the process | Responsibilities, statuses and financial processing |
We also check whether installed modules store their own data that the standard API does not expose. A B2B module or custom extension may hold essential business information. “Transfer products, customers and orders” is therefore not a complete integration specification.
Is CSV enough, or do you need an API?
A CSV import can suit a one-off data transfer or infrequent changes. An API integration supports regular, controlled exchange. Both methods can be combined, for example a prepared initial import followed by ongoing updates. The decision depends on data volume, change frequency and the available access methods.
For new stores, our clients normally create their own product records unless we have agreed an import or ERP integration. For migrations, the planned transfer of existing product data is part of the scope to assess. The quote should make this distinction clear.
Standard connector or custom development?
We first check whether an existing solution reliably covers the required processes. A suitable module can be more economical than building a new integration. Customisation becomes relevant when fields are missing, special pricing rules apply or standard workflows do not fit the business.
For Autolackpartner, we redesigned an existing VISMA ERP import module and added automated product image imports. For BILDHAU, we adapted and integrated the LogiFlex connection during a PrestaShop migration. Both examples show why we consider the retailer’s working practices, not just a list of technical features. Our documented PrestaShop projects.
What do existing integrations show in practice?
Ready-made connectors can provide a starting point for Odoo and PrestaShop. VentorTech’s connector lists products, stock, orders and specific prices among its features. Before extending or adapting it, we check which requirements are already covered and whether the Odoo deployment model is supported. Custom extensions must be technically possible, permitted by the licence and maintainable. VentorTech: features and requirements.
weclapp, Billbee and orgaMAX also document store integrations, but their data flows are not necessarily the same. HubSpot illustrates the distinction: the PrestaShop Data Sync connector reviewed here transfers customer data, not orders. A CRM connection and an ERP integration can complement each other while serving different purposes. HubSpot: PrestaShop connector scope.
Our article on ERP and inventory management for online stores explains which solutions may suit different needs. For implementation, we then agree exactly which data flows in each direction, where customisation is needed and who maintains the integration.
How much does an API integration cost?
A blanket price is not meaningful without a defined scope. Key factors include the number and type of data flows, source data quality, special rules, existing connectors, monitoring and testing requirements. Provider charges for APIs or connectors also belong in the calculation.
- Setup: access credentials, data mapping and configuration of an existing solution.
- Customisation: additional fields, pricing rules, status mapping or custom module resources.
- Data transfer: cleaning and initially importing existing information.
- Reliability: testing, error logs, retry mechanisms and documented responsibilities.
- Operation: monitoring and adjustments when connected systems change.
We recommend comparing quotes against the same workflows. What is included? Who resolves a failed transfer? Which later changes require a separate commission? This gives a more useful comparison than the module price alone.
Does an API automatically mean real-time updates?
No. An API initially provides an access method. How quickly a change appears in another system depends on polling intervals, events, processing and provider limits. A short delay may matter for available stock, while longer product descriptions often have different requirements. Agree and test the required update frequency for each data type.
A large catalogue also needs separate assessment of its initial import and subsequent changes. Holding 500,000 products and changing 500,000 products every day are different challenges. Check batch operations, request limits, image processing and recovery time after an interruption.
What should you test before going live?
We recommend tests based on real business events: a new product, a changed price, the last available item, an order, a partial shipment and a return. Add deliberate failure cases: an application temporarily unavailable, missing required data and a repeated transfer of the same order. Errors should be visible, data should remain traceable and orders should not be duplicated.
Permissions also matter. The connection should only be able to read or change the data needed for its task. Retest affected workflows after store or module updates. The documented resources and extension options in PrestaShop’s Webservice API provide a technical starting point, but do not replace checking the specific integration. PrestaShop: Webservice API.
Frequently asked questions
Is an API the same as a ready-made plugin?
No. An API provides technical access. A plugin or connector can use it for a particular task, adding data mapping, controls and error handling.
Are custom module data transferred automatically?
Do not assume so. Check where the data is stored and whether the connector or API exposes it. The integration may need to be extended.
Does ERP integration require rebuilding the store?
Not necessarily. If the platform and its extensions provide suitable access, an integration can often be added or improved. The technical condition of the store and the data exchange requirements determine what is possible.
Sources & further reading
- API definitions: IBM · accessed on
- VentorTech: features and requirements · accessed on
- HubSpot: PrestaShop connector scope · accessed on
- PrestaShop: Webservice API · accessed on