DEV Community: PermitCore

Offline licensing for a Python desktop app without calling home on every launch

PermitCore — Tue, 29 Sep 2026 18:48:19 +0000

Some desktop applications cannot depend on an internet connection every time they start. The useful security model in that case is not to hide a shared secret inside the Python package. It is to verify a signed license token locally with a public key.

The server keeps the private signing key. The application receives only the public verification key, so it can verify authenticity without gaining the ability to create new valid licenses.

I wrote a practical PermitCore guide for this flow:

pip install permitcore[offline]

On the first run, verify the signed token and bind it to the device:

from permitcore import PermitCoreClient

activated = PermitCoreClient.activate_offline(
    token, public_key_base64, device_id
)
if not activated.is_valid:
    raise RuntimeError(activated.message)

Later launches can validate the stored activation locally, with zero network calls:

result = PermitCoreClient.validate_offline(device_id)

A good test is to change one character in the activation token and confirm that signature verification fails. I would also test expired tokens, the wrong device, a missing local cache, and the customer workflow for moving to replacement hardware.

For device identity, avoid treating a raw MAC address as a permanent machine ID. It can change, it is privacy-sensitive, and virtual/network adapters make it unreliable. Use a stable identifier appropriate for the platform and define an explicit transfer policy.

The same product can then be published in PermitCore's built-in Store. The Store uses your Stripe account, takes 0% PermitCore commission, and delivers the license after checkout. That completes the full create → implement → sell path even for an offline-ready desktop edition.

Full walkthrough

How to add offline licensing to a Python desktop app

PermitCore

PermitCore is an early-stage developer-first startup, so feedback on the offline workflow and the guide is very welcome. 🙂🚀

Where license validation belongs in an Electron app

PermitCore — Tue, 29 Sep 2026 18:47:25 +0000

If an Electron app checks its license in renderer code, a customer can inspect the same code that makes the allow-or-block decision. That does not make the app impossible to protect, but it puts an important decision in the easiest process to inspect and modify.

For a paid Electron app, I prefer this boundary:

validate in the main process;
keep contextIsolation enabled;
expose only the minimum license status through a narrow preload/IPC API;
scope every validation request to the product ID;
test the packaged build, not only development mode.

The core integration can remain straightforward:

import { app } from 'electron';
import { PermitCoreClient } from '@permitcore/permitcore';

const client = new PermitCoreClient('https://api.permitcore.dev');
const result = await client.validate(
  licenseKey,
  app.getVersion(),
  productId
);

if (!result.isValid) app.quit();

I wrote a complete walkthrough covering installation, activation, product-scoped validation, offline grace, revoked-key testing, and the main-process/renderer boundary.

It also covers the step that licensing tutorials often omit: selling the application. PermitCore includes a branded Store, so the same product can have a checkout that uses your Stripe account, creates the license after payment, and delivers it to the customer. PermitCore takes 0% sales commission.

The intended workflow is create → implement → sell, without maintaining a separate storefront and webhook bridge just to issue keys.

Full walkthrough

How to license and sell an Electron app

PermitCore

If you ship Electron applications, I would be interested to hear how you currently separate licensing logic from renderer code and how you handle offline customers. 🙂🚀

A practical license-key flow for a .NET desktop app, including the sale

PermitCore — Tue, 29 Sep 2026 18:41:28 +0000

Adding a license check to a .NET desktop app is easy to underestimate. The first API call is usually the simple part. Production behavior is where the real work begins: product scoping, device activation, offline grace, license transfer, failed payments, and getting the key into the customer's hands.

I put together a .NET tutorial that treats licensing as a complete product flow rather than one IsValid check.

Install the client:

dotnet add package PermitCore.Client

Then validate the key against the application version and the exact product:

using PermitCore;
using System.Reflection;

var client = new PermitCoreClient("https://api.permitcore.dev");
var version = Assembly.GetEntryAssembly()?.GetName().Version?.ToString() ?? "1.0.0";

var result = await client.ValidateAsync(
    licenseKey,
    version: version,
    expectedProductId: productId);

if (!result.IsValid)
    return ShowActivationWindow(result.Message);

Before shipping, I would test at least these cases in the packaged application:

the correct license and product;
a valid license for a different product;
an expired or revoked license;
a device over its activation limit;
a temporary network failure while offline grace is available;
releasing an activation and moving the license to another computer.

The tutorial also finishes the commercial side. You can create a matching Store product, use one-time or recurring Stripe pricing, and have checkout generate and email the license. PermitCore uses the vendor's Stripe account and takes 0% PermitCore commission.

That is the distinction I wanted when building it: developers can create the license, implement it, and sell the software without maintaining a separate checkout-to-license webhook system.

Full walkthrough

How to add license keys to a .NET application

PermitCore

This is still an early-stage startup and I would especially appreciate feedback from people who ship WPF, WinUI, Avalonia, MAUI, or other desktop applications. 🙂🚀

How I added licensing and checkout to a Unity project without building two more systems

PermitCore — Tue, 29 Sep 2026 18:29:54 +0000

When I started working on software licensing, the part that bothered me was not only validating a key. A paid Unity game or asset needs the whole path: a product, a license policy, SDK integration, payment, and finally a way to deliver the right key to the customer.

Most licensing services stop after validation. You still need to connect a separate storefront, handle payment webhooks, generate the license, and send it to the buyer. That can become a second product to maintain before the actual game or tool has made its first sale.

I wrote a practical Unity guide showing the complete flow with PermitCore:

Create a product and choose device, version, and offline rules.
Install the Unity SDK through Package Manager.
Validate the license against the expected product ID.
Test revoked, expired, wrong-product, and activation-limit responses.
Publish the same product in a branded Store, connect your Stripe account, and let checkout issue and deliver the license automatically.

The integration itself stays small:

using PermitCore;
using UnityEngine;

var client = new PermitCoreClient("https://api.permitcore.dev");
var result = await client.ValidateAsync(
    licenseKey,
    Application.version,
    productId);

if (!result.IsValid)
    ShowLicenseScreen(result.Message);

The important detail is productId. A structurally valid key should not unlock the wrong game, asset, edition, or DLC. I also recommend testing a revoked key in the actual release build rather than stopping after the happy path works in the editor.

PermitCore's Store uses your own Stripe account and takes 0% PermitCore sales commission. The goal is to keep licensing and selling in one workflow: create → implement → sell.

Full walkthrough

How to sell licenses for a Unity game or asset

PermitCore

I am building this as a small developer-first startup, so feedback from Unity developers is very welcome. If something in the guide is unclear, you can reach me through Contact Us on the site. 🙂🚀

Why a licensing API is only half of the product

PermitCore — Mon, 21 Sep 2026 18:13:51 +0000

When we first looked at software licensing, the problem seemed straightforward: create a license key, validate it inside the application, and manage activations.

Then we reached the part where somebody actually has to buy the license.

That turns licensing into a much larger project. You need a product page, pricing, checkout, payment verification, customers, orders, subscriptions, license fulfillment, delivery, and somewhere for the customer to find what they purchased. The license API may be ready, but the commercial workflow is still another product to build and maintain.

That is the gap we are trying to close with PermitCore.

Create → implement → sell

PermitCore connects the full workflow:

Create a product and define its license rules.
Add validation with the REST API or one of eight official SDKs: .NET, Node.js, Python, Java, C++, PHP, Go, and Unity.
Publish the product in a customer-facing Store under your own brand.
Accept payment through your connected Stripe account.
Generate and deliver the working license automatically after checkout.

Products, prices, orders, customers, subscriptions, entitlements, and licenses stay connected instead of being split across a licensing dashboard, a custom checkout service, and several webhook handlers.

Why we made the Store part of licensing

Many licensing platforms treat commerce as an integration boundary.

For example, Keygen documents a Stripe flow where Stripe communicates with the licensing service through webhooks. LicenseSpring connects license fulfillment to services such as Stripe, FastSpring, and Shopify. Those are valid approaches, especially if a team already has a mature commerce stack.

But for an indie developer or a small software team, the missing checkout and fulfillment layer can become a second application. It has its own security work, failure states, support burden, and maintenance cost.

PermitCore takes a different approach: the Store is part of the licensing product. A vendor can go from defining a license to publishing the product for sale without building a separate commerce backend.

Your Stripe account, 0% PermitCore commission

Payments go directly through the vendor's connected Stripe account. PermitCore does not take a percentage of software sales.

That means the Store removes integration work without becoming a marketplace that sits between the vendor and the customer. Stripe still handles the payment relationship, while PermitCore connects a successful checkout to the correct order, entitlement, and license delivery.

When a separate commerce platform still makes sense

The built-in Store will not be the right answer for every business. If you already run a large Shopify, WooCommerce, or custom commerce operation, keeping that system and connecting fulfillment may make more sense.

Our goal is to give developers a complete default path when they do not want to build that entire layer themselves.

We are still a startup and continuing to produce documentation and videos, so our social channels are smaller than the product today. If you need anything while evaluating PermitCore, use the Contact Us page and we will help directly.

Website: https://permitcore.dev
Store overview: https://permitcore.dev/solutions/sell-license-keys
Product video: https://www.youtube.com/watch?v=148yf66x9IM
YouTube: https://www.youtube.com/@PermitCore
X: https://x.com/permitcore

How are you handling this in your own products: a custom checkout, an external commerce platform, or one connected licensing and sales workflow?

🙂🚀

Why we built PermitCore: software licensing shouldn’t become a second product

PermitCore — Thu, 10 Sep 2026 17:41:53 +0000

Hey DEV community,

I want to introduce PermitCore, a software licensing platform we built for independent developers and software teams.

The idea came from a problem we kept running into ourselves. Whenever we built software that needed licensing, we also had to build and maintain a separate system for license keys, device activations, expiration rules and customer access.

That infrastructure quickly started feeling like another product we had to maintain.

So we built PermitCore to handle it.

PermitCore currently supports:

License key creation and management
Device activation limits
Expiration and revocation
Offline license validation
Floating licenses and concurrent seats
Entitlements and feature access
Customer and reseller portals
Payments and webhooks
Zero-knowledge encryption
A REST API and SDKs for .NET, Node.js, Python, Java, C++, PHP, Go and Unity

There is a free plan that stays free, because we want indie developers to have something useful while getting their first products off the ground. We also offer a three-month free trial for anyone who wants to test the wider feature set without commitment.

PermitCore is still an early startup, and we’re continuing to improve both the product and our documentation. Our social channels are also fairly new, so I hope you won’t mind that there isn’t a huge amount of content there yet.

I’d really appreciate feedback from developers who have built licensing systems before or are currently deciding how to protect and sell their software.

Website: https://permitcore.dev

Documentation: https://permitcore.dev/docs/getting-started

YouTube: https://www.youtube.com/@PermitCore

X: https://x.com/permitcore

If you have any questions or need help integrating it, feel free to reach us through the Contact Us page on the website.

Thanks for taking a look 🙂 👋