Software licensing system: accounts, licences and REST API

A software licensing system for applications has four parts. The first is user accounts. The second is licences assigned to an account and to a specific application, with an expiry date. The third is a REST API (application programming interface) through which the application checks the licence when a user signs in. The fourth is a set of portals for the people who assign and buy licences. This is how we built INVENTA Licenses, a central user and licence system for INVENTA XR, a startup that makes VR training applications. Here are the decisions such a system requires and how we made them in this project.

When does an application need its own licensing system?

A simple application sold directly to customers can often manage with a licence key or a subscription in a payment gateway. A licensing system of your own makes sense when:

• licences are sold by intermediaries (distributors, partners, resellers) who create the customer accounts
• one customer uses several applications, each with its own licence and expiry date
• the applications run outside the browser (on computers, VR headsets, devices) and must check permissions through an API
• customers need a place where they can see their licences and request new ones

INVENTA Licenses meets all four conditions. The VR applications run on Windows, and time-limited licences are assigned by distributors. Customers sign in to the applications with accounts created by their distributor. We build systems like this as part of our SaaS and MVP development service.

The data model of a licensing system

Object	What it stores	What to watch
Application	name, description, availability	applications are added over time, so the list cannot be hard-coded
Distributor	company details, assigned customers	a distributor sees only its own customers
Customer (account)	sign-in details, assigned distributor	the account is created by the distributor, not the customer
Licence	customer, application, start and end date	a licence covers one specific application
Licence request	customer, application, handling status	a record of who asked and when

The most important decision is to assign a licence to the pair “account + application”. A licence assigned to the account alone would be simpler at the start. With the first new application, however, it would require rebuilding the model and migrating data.

Roles in a licensing system

INVENTA Licenses has three portals: administrator, distributor and customer.

• The administrator manages applications, distributors and accounts.
• The distributor assigns time-limited licences for individual applications to its customers.
• The customer signs in, browses the available applications and licence expiry dates, and requests new licences. The customer portal also has an FAQ and a contact form.

With this split, data isolation matters most. A distributor must not be able to see another distributor’s customers, even by changing an ID in the page address. That is why permissions are checked on the server with every request. Hiding buttons in the interface is not enough.

How does the application check a licence through a REST API?

The flow is simple. The user signs in to the VR application, and the application sends the sign-in details to the licensing system’s API. The API replies whether the account exists and whether the licence for this application is valid.

A few rules to adopt when designing such an API:

• The response distinguishes the reasons. “Wrong password”, “no licence for this application” and “licence expired” are three different messages for the user. Each means a different issue to sort out with the distributor.
• Server time decides validity. The clock on the user’s computer can be changed, so the application should not compare dates on its own.
• The API is versioned. You cannot update applications installed on customers’ computers all at once. Older versions must keep working for as long as anyone still uses them.
• Connections go over HTTPS only, and the number of sign-in attempts is limited to make guessing passwords harder.

What if the application has no internet connection?

There are three typical options. The choice has to be made at the very start of the project, because the architecture depends on it.

Option	How it works	When it fits
Connection required	without a response from the API, the application does not start	applications used where the internet is reliable
Grace period	the application remembers the last successful check and keeps working for a set time	short breaks in connectivity
Offline licence	a signed file or token with an expiry date, verified locally	workstations without network access

Each option is a trade-off between convenience for users and control over licences. In industrial plants, network access at a training workstation is not always a given. Discuss this decision with the people who know the places where the applications will be used.

Time-limited licences in practice

• The time zone of the end date matters. “Licence valid until 31 March” should mean the same moment for the distributor and for the application.
• A renewal must not leave a gap or cost the customer time they have paid for: a new licence assigned before the old one ends must not shorten the current period.
• A change history shows who assigned, extended or revoked a licence and when. In a dispute with a customer, it is the only source of truth.
• Customers should be able to see the end date themselves. Then a locked application comes as less of a surprise.

The technology behind INVENTA Licenses

The system is built with Next.js and React with TypeScript, a PostgreSQL database and Tailwind CSS, and runs in Docker containers behind Nginx. We use the same technologies in other projects, which makes maintenance easier. Our article on the software maintenance agreement explains what to put in the maintenance contract for such a system.

A licensing system is a good candidate for the first version of a product if the sales model relies on intermediaries from the start. See our article on what to include in an MVP for setting the scope.

Are you selling your application through partners, or do you need to control access to several applications from one system? Write to us. We start with your sales model and only then move on to the API.