DEV Community: JTL-Software Engineering

Turn your ERP Integration into a Cloud App

Demola Malomo — Thu, 01 Oct 2026 23:16:51 +0000

A new merchant calls. They just switched accounting software and want their JTL-Wawi (also known as ERP) orders to flow into it automatically. You know exactly what they need, because you've built it four times already.

So you do what you always do. You copy the last project, adjust the field mappings, and book a day to install it on their server. You set up remote access, test it, hand it over, and add a fifth deployment to your maintenance list.

It works. It pays. But somewhere around install number five, it's worth asking a different question: what if this build was an install instead of a project?

That's what Cloud Apps make possible. In this article, I'll walk through how to take an integration you keep rebuilding and turn it into an app you build once and install for every client. That includes the parts that stay the same, the parts that change, and the honest trade-offs.

If you're new to Cloud Apps, start with What are JTL Cloud Apps? first. This article assumes you know the basics.

What Per-client Integrations Really Cost

Custom integrations are a perfectly sensible way to build a business. A client has a specific problem; you solve it, charge for the work, and support the solution afterward. The problem starts when you solve the same problem over and over again.

Every installation is its own maintenance window. Five clients running your accounting export means five places where something can break, each with its own server, Windows updates, and security software.

Every JTL-Wawi upgrade is a small project. A client moves to a new version, and someone on your team has to check that the integration still works as expected. Then you do it again for the next client, and again with the next release.

Support starts with access. A good part of a support call can disappear before you even look at the problem. You need VPN access, remote desktop access, or someone at the merchant to give you access to the right system. Sometimes, the person who knows the admin credentials is the one person who happens to be on holiday.

Knowledge stays with people. The developer who built the original integration often knows the details that never made it into the documentation. They know why one client has a different mapping or why a particular workflow works the way it does. When that developer leaves, that context can leave with them.

Revenue is tied to hours. If you want to grow revenue from the same integration, you often need more implementations, more custom work, or more support. The integration can be valuable, but your ability to scale it is still tied to the people maintaining it.

None of this means the model is broken. It has built a lot of good businesses, maybe including yours. But it has a ceiling, and most agencies hit it without noticing.

You may Already have a Cloud App

You do not need to invent something new from scratch. Start with your existing projects. Take your last 20 JTL projects and group them by the problem they solved, rather than the client they were built for.

You're looking for four signals:

The same request keeps coming back. Three or more clients asked for roughly the same thing.
The logic stays the same and only the configuration changes. Different field mappings or thresholds, same core process.
The problem isn't tied to one merchant's quirks. It's something any merchant in that situation would need.
Clients would buy it without a meeting. If a merchant saw it in a store, they'd understand what it does and why they need it.

For example, you might find that your agency has repeatedly built:

accounting exports
shipping and label workflows
custom reporting dashboards
marketplace-specific data preparation
stock and purchasing alerts

If a group in your list ticks all four boxes, you've found a product. You've just been selling it as a service.

Your Clients Keep Using JTL-Wawi

One of the first questions you may have is: Does moving the integration to the cloud mean my client has to change their ERP?

No.

JTL-Wawi stays where it is. The merchant continues using Wawi as their ERP, while JTL Cloud provides the connection that allows a Cloud App to work with it. JTL describes this as a hybrid setup: Wawi continues to run locally, while cloud services and apps connect to it through JTL Cloud.

Connecting takes two steps on the merchant's side:

Connect Wawi to JTL Cloud. In the Admin menu, under JTL Cloud, they click Connect and sign in with their JTL ID.
Start the JTL-Wawi API with the cloud connection switched on. They do this in the JTL Administrator.

The only requirement is JTL-Wawi 2.2.0 or higher. The connection guide covers the full steps.
For an agency, this is good news twice over. Your existing clients are already the right audience. And helping them get connected is onboarding work you can offer as part of your service.

What stays and what changes

Moving from client-specific integrations to a Cloud App is less of a rewrite than it might sound. Much of what you have already built and learned still applies.

What stays	What changes
Your clients' Wawi installations	Where your integration runs
Your knowledge of JTL and merchant workflows	How the app accesses Wawi data
Your business logic and field mappings	Client-specific differences become configuration
Your client relationships	Updates are shipped from one application
Your existing technology choices	How merchants install and activate the app

The biggest change is the packaging. Instead of maintaining a separate integration for every customer, you build one application that can serve multiple merchants.

The access model changes too. Cloud Apps use defined API scopes, so you specify which JTL resources the app needs to access. Client-specific permissions and configuration can then be handled without changing the core application.

So the value is not in throwing away your existing integration. Your JTL knowledge, business logic, and understanding of merchant workflows are still the foundation. The Cloud App gives you a way to package that work for more than one customer.

The Path: Start with One Client

You do not need to turn your whole business into a product overnight. A practical way to start is with one client you already know well.

Step 1: Start with a willing client. Pick an existing client whose integration you understand and who is comfortable connecting their Wawi to JTL Cloud.

Step 2: Turn their integration into a private app. Private apps can be shared with specific merchants using activation codes, without going through the public App Store reviews. The client's workflow can stay largely the same while you move the integration into the Cloud App model.

Step 3: Add a second client. This is where you find out which parts of the integration are genuinely reusable. Differences that once lived in custom code now need to become configuration. That is the step where a client project starts becoming a product.

Step 4: Publish to the App Store. Once the app works across different merchant setups, you can submit it for review and make it available to a wider audience.

The important part is that you do not have to stop doing client work along the way. Your existing projects can give you the use cases, feedback, and revenue you need to build the product.

How your Business Changes

The shift is not from services to products. It is from building the same solution repeatedly to getting more value from something you have already built.

With a client-specific integration, most of the revenue comes from implementation and ongoing support. With a Cloud App, the same solution can be installed by multiple merchants. For App Store apps, JTL handles the merchant billing, while you manage your payouts through Stripe connect.

Your services business still has a role. It can move toward work where your expertise adds more value:

Onboarding: helping merchants connect Wawi and configure the app.
Customisation: handling requirements that fall outside the standard product.
Consulting: helping merchants improve their workflows around the app.

There is also a useful side effect: an app can become another way for potential clients to discover your agency. Someone may install the product for a specific problem and later need help with a larger project.

The Trade-offs

A Cloud App also comes with responsibilities that you may not have had with a one-off integration.

You own the application. Hosting, uptime, monitoring, and maintenance become part of the product. Managed hosting and basic monitoring can take care of much of the operational work.

You build for multiple merchants. Your app needs to keep each merchant's data and configuration separate. The JTL tenant becomes an important part of how you map a merchant to your own application data, so it is worth getting that model right early.

Public apps go through review. App Store distribution adds a review step. Starting with a private app lets you validate the product with real merchants before taking it public.

The merchant still depends on JTL-Wawi. Your Cloud App can only work with JTL-Wawi data when the required JTL-Wawi API connection is running. Make this part of onboarding and your support process so merchants know what to check if their connection stops working.

These are not unusual problems for a product business. They are simply the responsibilities that come with moving from maintaining individual integrations to maintaining an application that serves multiple merchants.

Where to Start

If you've read this far, you probably already have an integration in mind. Here's how to take the first step:

Read What are JTL Cloud Apps? if you skipped it, to see what the platform can do.
Follow the connection guide to connect a test Wawi to JTL Cloud.
Work through the quickstart to get a first app running inside the Cloud ERP.
Pick one client and plan their integration as a private app.

And if you're coming to JTL Connect, bring the integration you've built most often. We'll sketch it out as a Cloud App with you.

What are JTL Cloud Apps?

Demola Malomo — Thu, 01 Oct 2026 23:09:08 +0000

If you've built anything for the ERP system, you know the usual routine. A merchant needs something the ERP doesn't do out of the box, so you build it. Then you install it on their server, configure it for their setup, and keep it running. Then the next merchant asks for something similar, and you do it all again.

That model has kept a lot of agencies busy for a long time. It also has a ceiling. Every client is its own deployment and its own maintenance window, and every update has to be rolled out one install at a time.

Cloud Apps change that. In this guide, I'll cover what Cloud Apps are, what you can build with them, and why they're worth a serious look whether you run an agency, own a product, or write the code.

What are JTL Cloud Apps?

A Cloud App is a web application that you host and connect to JTL. It can appear directly inside the Cloud ERP, work with a merchant's JTL data through the platform APIs, and react to changes through webhooks. Merchants can get your app through the JTL App Store or, for customer-specific solutions, through private distribution with an activation code.

That means you can build a product around JTL without building a desktop extension, maintaining software on a merchant's machine, or asking users to leave their ERP every time they need your functionality.

How Cloud Apps Work

The architecture follows four moving parts:

Your app's frontend, which runs inside the JTL platform in an iframe and looks and feels like part of the product.
AppBridge, the channel between your frontend and the JTL platform. Your app uses it to ask for things like the current user's token or the record they're looking at.
Your backend, which talks to the JTL Cloud API and ERP to read and write merchant data.
Webhooks, which tell your backend when something happens in ERP, such as a new order or a stock change.

You host the frontend and backend wherever you like, on any cloud provider in any language. JTL handles the parts you'd rather not build yourself: identity, installation, permissions, and getting your app in front of merchants.

Where your App Shows Up

A Cloud App can meet the merchant in a few different places, and most apps combine two or three of them.

Menu items.

Your app gets its own entry in the Cloud ERP navigation and opens as a full page. This suits dashboards, configuration screens, and anything the merchant visits on purpose.

Context-aware Panels.

Panels are useful when the right information depends on what the merchant is currently looking at. For example, imagine a merchant opens a customer record; your app could show:

Recent support conversations
Outstanding balances from another system
Customer-specific recommendations

Backend automation.

Not every Cloud App needs a visible screen. You can also build services that work in the background using the JTL APIs and webhooks.

For example, a stock monitoring service could listen for inventory changes and notify a merchant when an item falls below a threshold. An integration could react to a new order and send the data to an external fulfillment or accounting system.

What can you Build with JTL Cloud Apps?

The better question isn't what kind of app you can build. It's what part of a merchant's workflow you can make better.

Here are a few examples:

A Reporting Dashboard

A retailer wants better visibility into sales performance than the standard reports provide.
You could build a menu item app that pulls data from ERP, combines it with data from other systems, and presents a dashboard for things like sales by channel, product performance, and inventory value.

The merchant gets a purpose-built view without having to export data and build spreadsheets every week. You build it once, and every merchant with the same question can install it.

A Customer Context Panel

You run a customer support tool. Your users keep switching between your helpdesk and the ERP to answer questions like "where's my order?" or "has this customer returned things before?"

You build a Panel that opens beside the customer record in the ERP and shows their open tickets and recent conversations. Now the support history sits next to the order history. Nobody copies customer numbers between tabs, and your product becomes part of the merchant's daily routine instead of another tool they have to remember to open.

Stock Alerts

A merchant's purchasing team keeps finding out about low stock after a product has already sold out. You build an app that subscribes to stock change webhooks, compares levels against thresholds the merchant sets, and posts an alert to their team chat or sends an email.

It's a small app, but it solves a problem that costs real money every time it happens. Small, focused apps like this are often the easiest to sell.

An Integration with an External Service

You offer a shipping, payment, or accounting service, and your customers want it connected to their ERP. Instead of a sync you maintain per client, you build a Cloud App. The merchant installs it, connects their account on your configuration page, and your backend takes it from there.

This pattern is useful for products where the main value comes from connecting JTL to something else.

How JTL Cloud Apps Differ from Traditional Extensions

If you're used to on-premises integrations, the biggest shift is where the responsibility sits. The table below compares the two models on the points that affect your day-to-day work.

	Cloud App	Traditional extension
Where the code runs	On your infrastructure	On or near the merchant's server
How updates reach merchants	Deploy once, every merchant has it	Rolled out per installation
How access is granted	Merchant grants scoped permissions at install	Credentials and network access per client
How merchants find you	App Store listing, plus private sharing	Sales calls and referrals
What you maintain per client	Their settings in your system	The whole deployment
How the app accesses JTL	Platform APIs, AppBridge and webhooks	Extension-specific integration mechanisms
User experience	Can appear inside the ERP	Depends on the extension model

The access model is one of the bigger differences.

With a Cloud App, you don't need to store a merchant's ERP credentials. The merchant grants your app specific permissions, and those permissions determine what the app can access. When the app acts on behalf of a user, the user's permissions also apply.

That gives you a clearer security model to work with and makes the conversation with a merchant's IT team much simpler: here's what the app needs access to, here's why it needs it, and here's what it can do with that access.

The other big difference is that the application itself is yours to run and operate. You can choose the web technologies, infrastructure, database, and deployment process that fit your product. You build and deploy the app on your own infrastructure, while JTL provides the platform APIs and app integration points it needs to work with the ERP.

This also changes how you think about distribution. Instead of deploying software into each merchant's environment, you can publish your app to the JTL App Store or share it privately with selected merchants. One application can serve multiple merchants without you maintaining a separate deployment for each one.

That's the basic shift with Cloud Apps: JTL provides the platform, and you own the application.

What are the Benefits of JTL Cloud Apps?

The benefits of Cloud Apps look different depending on your role.

For Business Owners

Cloud Apps can add functionality to the ERP without requiring another desktop application to install and maintain. That can mean fewer manual steps, fewer copy-and-paste workflows, and a more connected setup across the tools your business already uses.

For example, instead of exporting orders into another system every morning, a Cloud App can handle that process automatically in the background.

For Product Managers

Cloud Apps give you a way to build and distribute a product without managing a separate deployment for every merchant. You can focus the product on a specific merchant problem while relying on JTL's platform for the connection to the ERP.

This also gives you a straightforward distribution model. You can publish your app through the JTL App Store or share it privately with selected merchants.

For Engineers

Cloud Apps let you build a web application using the technologies and infrastructure you already know. You can use your own frontend, backend, database, and supporting services, then connect them to JTL through platform capabilities such as APIs, AppBridge, and webhooks.

Your application remains under your control, so you don't have to deploy and maintain a separate application inside every merchant's environment. JTL provides the integration points, while you own the application and its infrastructure.

Public vs. Private Cloud Apps: Choosing How to Distribute Your App

Not every app is built for the same audience, so you don't always need to distribute it in the same way.

A public app is built for broader distribution. The JTL App Store gives merchants a place to discover and install partner apps, making it a natural fit when you want to offer your product to a wider audience.

A private app makes more sense when you're building for a specific customer or a limited group of customers.

For example, an agency might build a custom integration for one retailer. A software company might pilot a new product with a handful of existing customers. In these cases, activation-code based distribution lets you give specific merchants access without publishing the app as a public marketplace product.

You can therefore start with the audience you actually have. A customer-specific integration doesn't need to become a public product before it can be useful. If you later decide to make it available more broadly, you can move toward public distribution as your product grows.

Start Building

The quickest way to judge whether Cloud Apps fit your business is to build one. The quickstart takes you from nothing to a working app running inside the ERP and pulling real data. Start with the quickstart, and create your app in the Partner Portal when you're ready.

If you're coming to JTL Connect, come and find us. Bring the integration you're maintaining today, and we'll talk through what it looks like as a Cloud App.