After more than 25 years of building web shops and B2B solutions I have arrived at a fairly simple conclusion: a good web shop does not start with design. It starts with data.
If a company runs Vasco as its ERP, business or accounting software, a large part of the key information is already in order. Items, partners, prices, stock, orders, business documents. There is no point maintaining the same data a second time, by hand, in the web shop.
That is why we have been connecting Vasco to web shops, B2B portals and B2C systems for years. The goal is always the same: each piece of data should have one reliable source, and every other system should use it automatically. That means less manual work, fewer errors and, above all, far more up-to-date data.
What connecting Vasco to a web shop actually means
In a well-designed integration Vasco is not just a program from which we export an Excel file once a day. It becomes one of the key data sources of the online business.
Vasco itself names web shops as a typical use case for its eAPI: an external system synchronises items, prices, stock and customers, and once a web order is placed it is transferred automatically into Vasco invoicing (FAW). If a new customer registers in the web shop, they are created in Vasco as well.
That is the essential difference. Instead of the chain web order, e-mail, review, manual customer entry, re-typing the items, checking the price, entry into Vasco, the process looks like this: web order, automatic transfer into Vasco, further processing in the existing business process.
People then deal with the order, not with re-typing the order.
Which data we usually connect
The scope of an integration always depends on the company's business process. I do not advocate automating everything just because it is technically possible.
First we determine where the master data lives. In one company Vasco is the master for items, prices and stock. Elsewhere product descriptions, photos and technical attributes are maintained in a PIM, while Vasco remains the master for commercial data. In a B2B project individual price lists, discounts, payment terms or multiple warehouses may be added.
In practice we most often connect:
- item and partner master data,
- stock per warehouse,
- list and B2B prices and discounts,
- orders and customers,
- other business documents where needed.
Vasco FAW is designed for wholesale, retail and stock management across any number of warehouses and includes customer orders, purchase orders, goods receipts, delivery notes, invoices and other sales documents. That makes it a very good foundation for an automated data flow between the business and the web.
Vasco eAPI or a direct connection to Firebird
This is one of the first technical questions in any serious integration.
The most standardised route is the Vasco eAPI, a programming interface through which an external application communicates with the Vasco programs. It supports master data and documents, and when writing data it applies the same validations Vasco itself uses. For many projects this is the cleanest solution.
There is a second route. Vasco runs its applications on a Firebird database; in 2025 they began the migration from Firebird 2.5 to Firebird 5.0. Because we know the Vasco environment well, on a suitable project we can also read data directly from the database. This is efficient mainly for reading large volumes of data, special synchronisations, existing installations, or when we need information that the specific API flow does not deliver optimally.
Direct database access is not automatically the "better" solution, though. For writing business data I prefer the official eAPI whenever the required functionality is supported through it. The reason is simple: the API is a controlled entry point into the business application and validates every entry. Working directly with the database, the developer must understand the data model, the relations between tables and the system's business logic very well.
So we choose the integration technology based on the process, not on which option sounds more technically advanced.
The biggest saving is not the server. It is the person.
Integrations come with a lot of talk about APIs, databases, JSON, SQL and synchronisation. I look at integration far more practically: how many times a day does someone enter the same data twice?
If an employee spends 30 minutes a day checking web orders and entering them into the accounting program, that is roughly 120 working hours a year. Add manual price corrections, stock checks, opening new customers and reconciling master data, and the number grows quickly.
Errors matter even more. Wrong item code. Wrong quantity. Old price. The web shows an item in stock that is not there. A partner in the B2B system sees the wrong discount. Every such error has a cost.
That is why I do not measure automation in clicks saved. I measure it in manual processes removed.
Vasco and B2B is an even more interesting combination
In a classic B2C web shop the customer usually sees one public price and buys. In a B2B system things get considerably more interesting.
A partner has their own price. Their own discount. Agreed terms. Access to only part of the range. Several branches, several users, a different view of stock. Order history and very fast re-ordering.
This is where, years ago, we at Spletko started developing our own B2B platform, TEC. Out of TEC2 the new generation TEC3 has grown, in which ERP integration is not an add-on bolted on at the end of a project but one of the key parts of the architecture.
With TEC3 the ERP remains the primary system for key business data, while the B2B platform handles the online side: users, individual price lists, partner portal, ordering, multiple languages, multiple markets and the other functions modern digital B2B needs. The Vasco connector is one of the standard ones.
One source of data matters more than one more feature
One of the biggest mistakes I see in web shop relaunches is a company holding the same data in several places. The price is in Vasco. A second price is in the web shop. The product description is in Excel. Stock is imported via CSV. Someone keeps their own spreadsheet. When something changes, nobody knows which value is correct anymore.
So when planning an integration we first define one master source for each piece of data, a single source of truth. For example:
- Vasco owns the item code, the commercial price and the stock.
- The PIM owns the long description, technical data and photos.
- The B2B or B2C platform merges this data and presents it to the customer.
- The order goes back into Vasco.
To me this architecture matters far more than whether the web shop has five or ten extra features. If the data foundations are wrong, every new feature only creates confusion faster. I wrote about what messy master data does to catalogue speed in the article on master data hygiene.
Why we know Vasco differently from someone reading the API documentation for the first time
We have worked with Vasco for many years and know their system very well. It shows in the integration.
Knowing how to send an API request is not enough. You have to understand what a partner, an item, a warehouse, a price, a customer order, a delivery note or an invoice mean inside the company, and how the client wants to use that data online.
In more than 25 years we have found that the best integrations are the ones users barely notice. The data is simply correct. Stock is current. The price is right. The order arrives where it should. And nobody re-typed it by hand.
Today at Spletko we build web shops, B2B portals, PIM connections and the TEC3 platform, and connect them to Vasco, SAOP, Datalab Pantheon, Opal and other business systems. ERP integration is no longer an extra feature of a web shop. It is the infrastructure of modern online sales.
When connecting Vasco to a web shop makes sense
My rule is very simple. If a piece of data already exists in Vasco and someone regularly transfers it by hand into another system, it is worth checking whether that step can be automated.
If you have a large number of items, change prices or stock frequently, receive many web orders, have B2B customers with individual terms or want to develop the online channel seriously, integration is usually no longer a luxury. It becomes the logical next step.
A good result is not just Vasco connected to a web shop. A good result is a business process in which data flows on its own and people step in where their work actually creates value.
If you use Vasco and are thinking about a web shop or B2B portal, write to me. In half an hour we usually see where most of the manual work is and what is worth automating first.
Frequently asked questions
Can Vasco be connected to a web shop?
Yes. Vasco has its own eAPI intended for connecting external applications and web shops. It supports synchronisation of items, prices, stock and customers and the transfer of web orders into Vasco FAW.
How do we connect Vasco to a B2B system?
We connect the B2B platform to Vasco via the eAPI or, where technically sensible, by reading the Firebird database that Vasco officially uses. We define which system is the master for items, prices, stock and partners, then automate synchronisation and order transfer.
Is the Vasco eAPI or a direct Firebird connection better?
It depends on the project. For controlled writing of partners, orders and other documents the eAPI is usually the right route, because Vasco applies its own validations. Direct access to the Firebird database is useful for demanding reads of large data volumes and specific synchronisations. The architecture is defined by data volume, synchronisation direction and the business process.
Which data can be automated between Vasco and a web shop?
Most often items, partners or customers, prices, stock and orders. The Vasco eAPI supports various master data and documents, including customer orders, quotations, goods receipts and invoices, so depending on the modules in use other data can be included as well.
Want to see TEC3 on your own data?
Write to us or reserve your place in the first wave of rollouts.