Software Licensing API: What to Look For

Every licensing API's marketing page reads roughly the same: "secure," "flexible," "developer-friendly." The differences that actually matter are underneath that, in specifics most vendors don't lead with. Here's what's worth checking before you pick one — including where PermitCore itself lands on each question, so you can compare against a real example rather than the abstract.

How does it actually store keys?

Ask specifically: is the plaintext key ever stored server-side, or only a keyed hash? A vendor that stores plaintext (even "encrypted at rest") means a database breach on their end can expose every key they've ever issued. PermitCore's approach: keys are encrypted client-side before they ever reach the server, and server-side lookup uses a keyed HMAC hash — the plaintext key itself is never stored anywhere on PermitCore's infrastructure.

What actually happens on activation-limit enforcement?

A seat limit sounds simple until you ask what happens under concurrent activation attempts near the limit — does the vendor guarantee exactly N seats, or can a race condition oversell one? This is genuinely easy to get subtly wrong (see our license key architecture post for why). Ask for specifics, not just "we handle concurrency."

Is offline support a real mechanism or a checkbox?

"Offline support" can mean anything from "we cache the last result" to "cryptographically signed tokens verified with zero network dependency." These solve different problems — ask which one you're actually getting, whether the token format is documented or proprietary, and what the vendor's own SDK code looks like for verification (if they won't show you, that's itself informative).

What's the actual anti-sharing mechanism?

Node-locking alone doesn't stop a valid key from being shared across many unrelated machines if there's no cross-device abuse detection — a shared key just looks like several individually-valid activations. Ask whether the vendor tracks request-volume and distinct-caller patterns per key, not just per-IP rate limiting (a different, narrower protection).

What happens if you outgrow them, or they shut down?

This is the question almost nobody asks upfront and almost everybody wishes they had. Can you export your data if you migrate away? If the vendor stops operating, does every license issued through them instantly stop validating for every one of your existing customers? A serious answer includes a real continuity story — self-hosting the verification path, or at minimum offline tokens that keep working with no ongoing dependency on the vendor being reachable. See our full breakdown of this specific question.

Is the pricing model actually shaped like your product?

A per-seat model fits a desktop app poorly if your product is metered/usage-based, and vice versa. Check whether the vendor supports the licensing model your product actually needs (node-locked, floating, metered, feature-gated — often more than one at once) rather than forcing your product to fit their pricing structure.

Does selling licenses require a separate payment integration?

If you're selling directly to end customers, check whether license issuance and payment are actually connected — does a successful Stripe checkout automatically issue a license, or is that a separate integration you have to build yourself? And check the commission: some platforms take a cut of every sale on top of normal payment processing fees, others don't.

None of this is meant to make the decision for you — see our build vs. buy breakdown if you're still weighing whether to use a vendor at all, and our honest comparison of a few real options if you've decided to buy and want specifics.