JTL-Wawi API: what really works for CRM integrations
JTL-Wawi has no classic REST API, but its data is accessible. This guide shows which objects you can read out, why reading is harmless and writing is tricky, and when you need a dedicated middleware for a CRM connection.
In short: the data is there, the path is the database
JTL-Wawi is a Windows application that stores its data in a Microsoft SQL Server database. There is no public REST API in the sense of cloud software. Still, you get to the data well: through exactly this database and through JTL-Ameise, the built-in import/export tool.
For a CRM connection that means: reading customers, companies and orders is reliable and harmless. Writing back into the Wawi is the tricky part and needs a different solution. What such a connection looks like as a whole is on the page about which CRM fits JTL-Wawi, and in detail for customer data in HubSpot.
- What is the JTL-Wawi API?
- JTL-Wawi API usually does not mean a single REST endpoint, but access to the Wawi data at all. In practice it consists of two paths: direct, read-only access to the Microsoft SQL database (eazybusiness) where the Wawi stores everything, and JTL-Ameise for the controlled import and export of whole object lists. A CRM connection almost always uses the read-only database path and lets a middleware carry the data into the CRM.
What you can read – and what may go back into the Wawi
Almost every Wawi object can be read out. The more interesting question is the other direction: what can be written back safely? The highlighted column shows the harmless path.
For a CRM connection only the left column counts: reading customers, companies and order headers. The rest stays in the Wawi, where it belongs.
Why reading is easy and writing causes trouble
Reading from the JTL database is harmless. A user with read-only rights can query customers, companies and orders without ever changing anything. Even if the connection stumbles, the Wawi stays untouched – which is why nearly every serious CRM integration is built exactly this way.
Writing directly into the database is a different matter. The tables carry triggers and relations that JTL maintains itself and can adjust with every update. Anyone writing in via SQL bypasses this logic and risks inconsistent records that only surface weeks later. If something really has to go back into the Wawi, the path runs through JTL-Ameise or the interfaces provided for it.
Raw SQL writes into the Wawi database are not an official path and can break on the next JTL update. For the rare case where data has to go back, Ameise is the right tool – controlled and documented.
Why it needs a middleware
Ready-made connectors between JTL-Wawi and the common CRMs are rare. A middleware like n8n closes the gap: it reads from the database, reshapes the data, checks for duplicates and writes it into the CRM. Here is how such a connection runs.
A database user with read-only rights is enough for the sync. It sees the tables of the eazybusiness database but cannot change anything – so a connection can never damage Wawi data in operation.
The whole Wawi does not need to leave. Usually customers with address and contact, in B2B the company and the order headers, are enough. Articles, stock and purchase prices stay in the Wawi.
A tool like n8n reads the chosen fields from the JTL database, checks for duplicates and creates or updates the contacts in the CRM. It fetches new or changed records on a schedule, hourly or nightly.
It is tested with real orders from your Wawi. Once the sync runs, the middleware monitors itself and reports errors instead of swallowing them silently.
The technical frame behind it is the same as for other systems without a ready-made interface – covered under CRM integration. How you then enrich the transferred contacts in the CRM with industry and company size is in the guide on HubSpot interfaces.
Unsure whether the data in your Wawi is enough for a CRM connection? Send me a short note on which objects you work with – I'll tell you what is realistic.
Example: pulling customers from the Wawi into the CRM
A merchant wants to see their existing customers and every new order in the CRM automatically, instead of exporting lists. Here is how the maths compares to doing it by hand.
Where the database path hits limits
Access through the database is reliable, but it has three honest limits worth knowing up front.
The middleware polls for changes on a schedule, hourly or nightly. For a CRM that is almost always enough – a new customer rarely needs to show up within the second, but reliably on the same day.
The server with the Wawi database must be reachable for the middleware – locally, via VPN or through a properly secured access. For pure cloud setups without database access it gets more involved.
JTL adjusts the database with updates. A good connection catches this instead of stalling on every new version – which is why monitoring belongs in from the start.
Frequently asked questions about the JTL-Wawi API
Book a free intro call
Tell me which objects from your JTL-Wawi should go into the CRM and what your setup looks like. I'll tell you honestly what works through the database path and what doesn't.
Pick a time →I build connections between warehouse management, CRM and internal tools, often with n8n as middleware and the JTL database as the source. This page sums up what is technically possible in real JTL projects and where you're better off keeping away from raw database writes.
Auf LinkedIn vernetzen →Bring JTL-Wawi data into the CRM
Tell me which objects you want to transfer and how many customers and orders come together per month. In the intro call I estimate effort and path before anything is built.
- Free intro call, about 15 minutes
- Clear read: which data path and which fields
- Honest look at data volume, schedule and limits