How to Add Licensing to Your SaaS or App (2026)

You have a product and you have plans. Now you need to actually enforce them — check who is allowed to use what, cut off a customer who cancelled, gate a paid feature behind the right tier. That layer is licensing, and you can add it to an application with a handful of API calls instead of building a licensing system from scratch. Here is where the check goes, how to read and enforce entitlements, and how to keep it honest against a client you should never fully trust.

What "adding licensing" actually means

Under the marketing word, licensing is four concrete jobs:

• Identify the customer or install — a license key they hold.
• Validate — is this key real, active, and not expired or revoked?
• Read entitlements — what does this customer’s plan allow (features, seats, quotas)?
• Enforce and track — unlock the right features, and record which devices are using the license.

A license key on its own only does the first two. The value is in the last two — which is the difference between a key and an entitlement.

The core loop

The end-to-end path is short: create a product, issue a license key for a customer, then validate that key from your app. Validation is a single call with your secret API key:

POST /api/v1/integration/licenses/XXXX-XXXX-XXXX-XXXX/validate
X-API-Key: <your-api-key>          # keep it server-side, never in shipped code

-> {
  "data": {
    "valid": true,
    "license": { "status": "active", "entitlements": { "plan": "pro" } }
  }
}

Read data.valid to decide access, and data.license.entitlements to decide what to unlock. The exact request and response are in the license-key API guide, and the copy-paste quickstart (curl, PHP, and JavaScript) runs the whole flow in a few minutes.

Put the check on your server, not the client

This is the part that decides whether your licensing is real. A check that runs only inside the client can be patched out by anyone who wants to; a validation that runs on your server, with your secret API key, cannot — and it keeps the key out of shipped binaries. The pattern:

• Validate server-side with your API key; never embed that key in client code.
• Cache the result briefly (minutes) so you are not calling on every request.
• Fail gracefully — if the licensing call is unreachable, fall back to the last good result or a short grace window rather than locking a paying customer out.
• Treat the client as untrusted. Whatever the app decides on top of the check is only as trustworthy as the app; the server call is the source of truth.

For software that genuinely cannot call a server on each check — CLIs, desktop, air-gapped — swap the online call for a signed token the client verifies locally, covered in offline license verification. Same rule holds: trust nothing beyond the signature.

Read and enforce entitlements

Once the key is valid, the entitlements drive your feature gates: a boolean per feature, a seat count, a monthly quota, the plan name. Keeping those as data rather than hard-coded plan logic means you can change what a plan includes — or grandfather one customer — without re-issuing keys or shipping a build. Enforce hard limits (block past the cap) or soft limits (allow and meter) per feature, and record usage idempotently so a retry does not double-count.

Track installs with activations

If your plans include device or seat limits, record an activation when a customer installs: send a stable, unguessable instance_id your app generates once per install (a random UUID you persist — never a shared or guessable value), plus an optional device_fingerprint. That is what lets "3 seats" mean three real installs rather than three strings the client felt like sending. The activation model and its seat-release path are covered in the docs.

Build vs. buy

Everything above — key issuance, validation, entitlements, activation limits, renewal, revocation, and an audit trail — you can build yourself. It is also a standing system to run and secure that has nothing to do with your product, which is the whole build-vs-buy question. ValidonX provides those building blocks as an API, so "add licensing" is a few calls and a server-side check — the model behind licensing as a service.

Frequently asked questions

How do I add licensing to my app?

At minimum: give each customer a license key, and have your app validate that key against a licensing API before unlocking paid features. A complete solution also reads entitlements (what the customer’s plan allows), tracks activations (which devices or installs are using the license), and handles renewals and revocation. With an API-first licensing service the core loop is a few calls — issue a key, validate it, read entitlements — rather than a system you build and run yourself.

Should I validate the license on the client or the server?

On your server whenever you can. A check that runs only in the client can be patched out; a server-side validation using your secret API key cannot, and it keeps the key out of shipped code. Validate server-side, cache the result briefly to avoid a call on every request, and treat the client as untrusted. For software that genuinely cannot call a server on each check (CLIs, desktop, air-gapped), use a signed token the client verifies cryptographically — and still trust nothing beyond the signature.

How long does it take to add licensing with an API?

The core loop — issue a key, validate it, read entitlements — is only a few API calls, and ValidonX’s quickstart runs it end to end in minutes. The real work is product decisions: what your plans include and where each feature gate lives in your app. The licensing plumbing itself is not the slow part when you use a licensing API instead of building the server.

What is the difference between a license key and entitlements?

The key answers "is this valid?"; entitlements answer "what is this customer allowed to do?" You validate the key, then read its entitlements — features, seat counts, quotas, plan — to decide what to unlock. Separating the two means you can change what a plan includes as data, without re-issuing keys or shipping a new build.

Do I need to build my own licensing server to add licensing?

No. You can, but a production licensing system is key issuance, validation, entitlements, activation limits, renewals, revocation, and an audit trail — a large surface area that has nothing to do with your actual product. A licensing API or service gives you those building blocks so you add licensing by calling an endpoint, not by operating a licensing server.

Ready to add licensing without building the server? Start free — issue a key, validate it, and read entitlements in minutes, no credit card.