DEV Community: Traffic Orchestrator

Building a Domain-Bound Software Licensing System: Architecture Deep Dive

Traffic Orchestrator — Wed, 01 Apr 2026 01:43:45 +0000

TL;DR

We built a licensing system that cryptographically binds software licenses to specific domains. This post walks through the architecture decisions, security model, and real-world patterns we use in production.

The Problem

Most software licensing systems rely on API keys or serial numbers. The issue? These are trivially shareable. One customer buys a license, shares the key on a forum, and suddenly your entire customer base is using a single license.

We needed something better: a system where licenses are cryptographically bound to specific domains, making unauthorized sharing technically impractical.

Architecture Overview

Our licensing system has three core layers:

License Generation — Creates signed, domain-bound tokens
Validation Engine — Verifies licenses both online and offline
Enforcement Layer — Handles grace periods, trial expiry, and usage metering

License Structure

Each license is a signed JWT containing:

{
  "sub": "lic_abc123",
  "domain": "example.com",
  "plan": "professional",
  "features": ["analytics", "webhooks", "custom-domains"],
  "limits": { "apiCalls": 50000, "seats": 10 },
  "iat": 1711929600,
  "exp": 1743465600
}

The domain binding is the critical piece. When a license is validated, we compare the requesting domain against the domain claim. Mismatches are rejected.

Domain Binding: How It Works

The binding happens at two levels:

1. Server-Side Validation

When your application calls our API to validate a license:

const response = await fetch('https://api.example.com/v1/licenses/validate', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    licenseKey: 'lic_abc123',
    domain: window.location.hostname
  })
})

const { valid, features, limits } = await response.json()

The API checks:

Is the license key valid and not expired?
Does the requesting domain match the bound domain?
Is the license within its usage limits?
Has the customer's subscription been canceled or suspended?

2. Offline Validation

For applications that need to work without internet access, we provide offline validation using public key cryptography:

import { verify } from './license-verifier'

const result = verify({
  licenseKey: 'lic_abc123',
  publicKey: EMBEDDED_PUBLIC_KEY,
  currentDomain: window.location.hostname
})

if (result.valid) {
  enableFeatures(result.features)
}

The license token is signed with our private key. The SDK ships with the corresponding public key, so it can verify the signature without calling home.

SDK Architecture

We ship SDKs for 9 languages:

Language	Package Manager	Validation
Node.js	npm	Online + Offline
Python	PyPI	Online + Offline
Go	Go modules	Online + Offline
Ruby	RubyGems	Online
Java	Maven Central	Online + Offline
.NET	NuGet	Online + Offline
Rust	crates.io	Online + Offline
PHP	Packagist	Online
Django	PyPI	Online (middleware)

Each SDK follows the same pattern:

# Python example
from traffic_orchestrator import LicenseClient

client = LicenseClient(api_key='your_api_key')

# Validate on every request (middleware pattern)
result = client.validate(
    license_key='lic_abc123',
    domain='customer-app.com'
)

if result.valid:
    print(f'Plan: {result.plan}, Features: {result.features}')
else:
    print(f'Invalid: {result.error}')

Security Model

Several layers prevent abuse:

Rate Limiting

Validation endpoints are rate-limited per API key. Excessive requests trigger progressive delays, not hard blocks — we don't want to break legitimate applications.

Replay Protection

Each validation response includes a nonce. Replaying a captured response fails because the nonce won't match.

Certificate Pinning

Our SDKs pin the API's TLS certificate. This prevents MITM attacks where someone might try to intercept validation requests and return spoofed "valid" responses.

Webhook Notifications

When suspicious activity is detected (validation from unexpected domains, burst requests), we fire webhooks to the customer's configured endpoint:

{
  "event": "license.suspicious_activity",
  "data": {
    "license_id": "lic_abc123",
    "reason": "domain_mismatch",
    "requested_domain": "pirated-site.com",
    "bound_domain": "legitimate-app.com"
  }
}

Lessons Learned

1. Grace Periods Matter

Don't immediately kill access when a license expires. We give a 7-day grace period where the license still works but returns "grace": true in the response. This gives developers time to renew without breaking their users' experience.

2. Offline-First Design

We assumed most customers would always have internet. Wrong. Many enterprise customers deploy behind firewalls. Offline validation went from "nice to have" to "critical feature" within our first month.

3. Feature Flags > Plan Names

Instead of checking plan === 'pro', we expose individual feature flags. This decouples your code from our pricing model. When we restructure plans, your code doesn't break.

// Bad: Coupled to plan names
if (license.plan === 'professional' || license.plan === 'enterprise') {
  enableAdvancedFeatures()
}

// Good: Decoupled via feature flags
if (license.features.includes('advanced-analytics')) {
  enableAdvancedFeatures()
}

4. Usage Metering Must Be Async

Don't block the validation response while recording usage. We fire-and-forget usage events to a queue, which are processed asynchronously. This keeps validation latency under 100ms.

What's Next

We're working on:

Terraform provider (already live!) for infrastructure-as-code license management
Usage-based billing integration with Stripe
Multi-domain licenses for enterprise customers with multiple properties

If you're building a SaaS product and struggling with license management, we'd love to hear about your use case. Drop a comment or check out our documentation.

What licensing challenges have you faced in your projects?

Domain-Bound vs Traditional License Keys: A Security Deep Dive

Traffic Orchestrator — Tue, 31 Mar 2026 19:29:34 +0000

Traditional license keys have a fundamental flaw: they can be shared.

A single string like XXXX-YYYY-ZZZZ-AAAA can be copied, pasted into a forum, or shared across an entire office. There's no inherent binding between the key and who should be using it.

Domain-bound licensing solves this by tying your license to the domain where your software actually runs.

The Problem with Traditional Keys

Traditional license key validation checks a single string against a database. That means:

Keys get posted on forums and piracy sites
One purchase = unlimited installations
No way to enforce per-customer terms
Revoking a shared key punishes legitimate buyers too

How Domain-Bound Licensing Works

Instead of validating just a key, domain-bound licensing validates the combination of key + domain. The server checks:

Is this license key valid?
Is this domain authorized for this key?
Has the domain limit been exceeded?
Is the subscription active?

If any check fails, validation is denied — even with a valid key.

Security Comparison

Attack Vector	Traditional Keys	Domain-Bound
Key sharing	❌ Vulnerable	✅ Protected
Forum leaks	❌ Vulnerable	✅ Protected
Offline cracking	❌ Possible	✅ Ed25519 signatures
Replay attacks	❌ Often unprotected	✅ Timestamp + nonce
Domain spoofing	N/A	✅ Server-side validation

Offline Validation with Ed25519

What about environments without internet access? Cryptographic signatures enable offline validation. The signed payload contains the domain, expiration, and feature set — cryptographically tamper-proof without needing a network call.

This means your customers can validate licenses even in air-gapped environments, on-premise deployments, or regions with unreliable connectivity.

Performance

Traditional license servers add 200-500ms of latency per validation. With edge computing, domain-bound validation can happen in under 50ms at 300+ global locations.

License checks shouldn't slow down your customers' experience.

When to Use Each Approach

Traditional keys work fine if:

Simple desktop app with no internet requirement
You don't care about key sharing
Your product is low-cost and piracy isn't a concern

Domain-bound licensing is better if:

Selling to businesses (SaaS, WordPress plugins, web apps)
Need to enforce per-domain pricing
Revenue protection matters
Want real-time usage analytics

We built Traffic Orchestrator to make domain-bound licensing accessible to every software company. Check out our documentation to get started.

Validate Software Licenses in 10 Lines of Code (Any Language)

Traffic Orchestrator — Tue, 31 Mar 2026 19:27:41 +0000

Adding license validation to your software shouldn't require a PhD in cryptography. Here's how to do it in 10 lines (or less) across popular languages.

The API

Every example below calls the same REST endpoint:

POST /api/v1/license/validate
Content-Type: application/json

{
  "license_key": "your-key",
  "domain": "customer-domain.com"
}

Response:

{
  "valid": true,
  "plan": "professional",
  "features": { "max_domains": 10, "api_calls": 50000 }
}

Now let's implement it everywhere.

JavaScript / Node.js

const validateLicense = async (key, domain) => {
  const res = await fetch('https://api.trafficorchestrator.com/api/v1/license/validate', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ license_key: key, domain })
  });
  return res.json();
};

Python

import requests

def validate_license(key, domain):
    r = requests.post('https://api.trafficorchestrator.com/api/v1/license/validate',
                       json={'license_key': key, 'domain': domain})
    return r.json()

Go

func validateLicense(key, domain string) (map[string]interface{}, error) {
    body, _ := json.Marshal(map[string]string{"license_key": key, "domain": domain})
    resp, err := http.Post("https://api.trafficorchestrator.com/api/v1/license/validate",
        "application/json", bytes.NewBuffer(body))
    if err != nil { return nil, err }
    defer resp.Body.Close()
    var result map[string]interface{}
    json.NewDecoder(resp.Body).Decode(&result)
    return result, nil
}

Ruby

require 'net/http'
require 'json'

def validate_license(key, domain)
  uri = URI('https://api.trafficorchestrator.com/api/v1/license/validate')
  res = Net::HTTP.post(uri, { license_key: key, domain: domain }.to_json,
                       'Content-Type' => 'application/json')
  JSON.parse(res.body)
end

PHP

function validate_license($key, $domain) {
    $response = wp_remote_post('https://api.trafficorchestrator.com/api/v1/license/validate', [
        'headers' => ['Content-Type' => 'application/json'],
        'body' => json_encode(['license_key' => $key, 'domain' => $domain])
    ]);
    return json_decode(wp_remote_retrieve_body($response), true);
}

cURL (Bash)

curl -X POST https://api.trafficorchestrator.com/api/v1/license/validate \
  -H "Content-Type: application/json" \
  -d '{"license_key":"your-key","domain":"example.com"}'

Rust

async fn validate_license(key: &str, domain: &str) -> Result<serde_json::Value, reqwest::Error> {
    let client = reqwest::Client::new();
    let body = serde_json::json!({"license_key": key, "domain": domain});
    let res = client.post("https://api.trafficorchestrator.com/api/v1/license/validate")
        .json(&body).send().await?.json().await?;
    Ok(res)
}

C# / .NET

async Task<JsonElement> ValidateLicense(string key, string domain) {
    var client = new HttpClient();
    var content = new StringContent(
        JsonSerializer.Serialize(new { license_key = key, domain }),
        Encoding.UTF8, "application/json");
    var response = await client.PostAsync(
        "https://api.trafficorchestrator.com/api/v1/license/validate", content);
    return JsonSerializer.Deserialize<JsonElement>(await response.Content.ReadAsStringAsync());
}

What You Get Back

Every successful validation returns:

Field	Type	Description
`valid`	boolean	Whether the license is valid for this domain
`plan`	string	The plan tier (builder, starter, professional, business, enterprise)
`features`	object	Plan-specific feature limits
`expires_at`	string	When the license expires (ISO 8601)

Error Handling

Always handle failures gracefully:

const result = await validateLicense(key, domain);

if (!result.valid) {
  // Show upgrade prompt, not a hard block
  showUpgradeNotice(result.error);
} else {
  enablePremiumFeatures(result.features);
}

Pro tip: Cache validation results locally for 5-15 minutes to reduce API calls and handle temporary network issues.

Traffic Orchestrator provides SDKs for all these languages (and more) with built-in caching, retry logic, and offline fallback. Get started free.

How We Built Edge-First License Validation in Under 50ms

Traffic Orchestrator — Tue, 31 Mar 2026 16:57:09 +0000

TL;DR

We built a licensing API where license validation happens at the CDN edge - not a centralized server. The result: sub-50ms validation times globally.

The Problem

Most licensing APIs work like this:

Your app makes an HTTP request to a central server
The server queries a database
The result comes back 200-500ms later
Your users wait

That is unacceptable for performance-critical applications.

Our Approach: Edge Validation

Instead of a central server, Traffic Orchestrator validates licenses at edge nodes distributed globally. Here is what the integration looks like:

const response = await fetch('https://api.trafficorchestrator.com/api/v1/licenses/validate', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-API-Key': 'your-api-key'
  },
  body: JSON.stringify({
    license_key: 'LIC-XXXX-XXXX',
    domain: 'customer-app.com'
  })
})

Domain-Bound Security

License keys are cryptographically bound to specific domains. This means:

Keys cannot be shared across unauthorized domains
Validation includes origin checking
No complex hardware fingerprinting needed

What is Available Today

12 SDK packages across every major language
Real-time analytics dashboard
Free Builder tier to get started
Webhook notifications for license events

Check it out at trafficorchestrator.com

What is your current approach to software licensing? We would love to hear what pain points you have experienced.

Why Most Software Licensing APIs Are Broken

Traffic Orchestrator — Tue, 31 Mar 2026 16:57:09 +0000

Most licensing solutions are slow, bloated, and painful to integrate.

We spent months building Traffic Orchestrator, a licensing API that validates at the edge in under 50ms.

What makes it different

Edge validation - License checks happen at the CDN edge, not a centralized server
Domain-bound keys - Licenses are cryptographically tied to specific domains
12 SDK packages - Drop-in integration for every major language
Real-time analytics - See license usage as it happens
Free tier - Get started without a credit card

TL;DR

We built a licensing API that prioritizes developer experience and performance. No bloated SDKs, no slow validation, no vendor lock-in.

Check it out: trafficorchestrator.com