Integrate and extend Easy License Manager.

01 Orientation

There are two integration surfaces. The customer's deployed software calls the store's REST API to activate a license, validate it, check for updates and download packages. Separately, code running inside WordPress — or a remote tool over REST, WP-CLI or MCP — can query and extend licensing data.

The REST endpoints are a frozen, versioned contract. Slugs, parameters, response shapes, error codes and the salt formula never change, because licensed products already deployed on third-party sites depend on them. Build against them with confidence.

02 Integration REST API

The endpoints are registered on the legacy WooCommerce API and reached at /wc-api/{slug}/.

License activation

Activates a key for a site, returns a per-activation salt, and reports activation/validation state. Accepts GET or POST; all values pass through rawurldecode().

Success — JSON, frozen key order

{
  "activated": true,
  "message": "2 out of 3 activations remaining",
  "time": 1730000000,
  "license": "valid",
  "salt": "e9c84f1b…md5"
}

Error response

Errors are JSON with an error, code and activated: false.

{
  "error": "<strong>Error #20010:</strong> No matching license key exists. Activation error",
  "code": "20010",
  "timestamp": 1730000000,
  "activated": false
}

Software update

Single and bulk update checks, plugin information, and the latest-version binary download. The salt is compared against the stored activation salt; a mismatch is an error.

Secure download

Serves a product package only to a logged-in customer who owns an active license for it. The resolver is path-traversal-safe: it resolves realpath() of both the candidate and the base directory and rejects anything not contained within it.

Remove activation

Removes a single activation. Guarded by a sacred per-activation nonce built into the My Account “remove” link and verified with hash_equals().

The salt

On a successful activation the store returns a per-activation salt. The client stores it and re-sends it on every later validation and update check; the store compares it against the stored activation salt. Its role is to bind subsequent calls to a specific activation — it is never exposed by any read channel.

03 Read / query API

A read-only API for fetching license information, exposed through four channels from a single source of truth. All four call the same facade and run output through the same redacting serializer, so they answer identically.

PHP

The Query facade returns immutable DTOs; the helpers return redacted arrays.

// Canonical entry point: the facade (immutable DTOs).
$query    = license_manager_query();
$license  = $query?->get_license( 42 );

// Helpers return redacted arrays — the salt is never included.
$count    = lmfwc_count_user_licenses( 99 );
$licenses = lmfwc_get_user_licenses( 99 );
$acts     = lmfwc_get_license_activations( 42 );

REST — WordPress Abilities API

Abilities are registered under the license-manager category.

# List abilities — auth via Application Password (HTTP Basic)
curl -u "admin:xxxx xxxx xxxx xxxx" \
  "https://store.com/wp-json/wp-abilities/v1/abilities"

# Example input for license-manager/get-user-licenses
{ "user_id": 99 }

MCP — Model Context Protocol

The bundled official wordpress/mcp-adapter exposes every ability as an MCP tool.

# HTTP: POST /wp-json/mcp/mcp-adapter-default-server
# STDIO:
wp mcp-adapter serve \
  --server=mcp-adapter-default-server \
  --user=admin

WP-CLI

The wp license-manager command set.

wp license-manager get-license 42 --user=admin
wp license-manager user-licenses 99 --format=json
# alias
wp lmfwc count-user-licenses 99

04 Authentication & redaction

Authentication

Remote REST and MCP access authenticates with standard WordPress Application Passwords (HTTP Basic Auth against the REST API). There is no separate scheme; the authenticated user's capabilities drive each ability's permission check.

Redaction policy

Output is redacted in one place — the serializer — and applies to all four channels:

• The activation salt is never emitted anywhere.
• The license key is emitted only to the owner or a capability holder.
• Owner identity is emitted only to a capability holder.
• User-scoped abilities let a non-privileged caller query only their own user id.

The gating capability is filterable

add_filter(
  'license_manager_api_capability',
  static function( string $cap, string $context ): string {
    return 'manage_woocommerce'; // e.g. allow shop managers
  },
  10, 2
);

05 Extending the plugin

Add behaviour from outside, without forking. The plugin fires neutral license_manager_* actions across the lifecycle.

Filters

User-facing strings, queries and responses are filterable by design. A few of the most useful:

Pluggable subscription engines

Subscription support is an abstraction. Register your own provider through one filter.

// Add a subscription engine without touching the core.
add_filter(
  'license_manager_subscription_providers',
  function( array $providers, $manager ): array {
    $providers[] = new My_Engine_Provider();
    return $providers;
  },
  10, 2
);

06 Code examples

Copyable examples for the common tasks.

Activate a license (client → store)

curl "https://store.com/wc-api/lm-license-api" \
  --data-urlencode "action=activate_license" \
  --data-urlencode "license=3F9A-7C2E-B41D-88Aa" \
  --data-urlencode "item_name=Acme Pro" \
  --data-urlencode "site_url=https://customer.com"

Check for an update (client → store)

curl "https://store.com/wc-api/upgrade-api" \
  --data-urlencode "action=plugin_latest_version" \
  --data-urlencode "license=3F9A-7C2E-B41D-88Aa" \
  --data-urlencode "item_name=Acme Pro" \
  --data-urlencode "slug=acme-pro/acme-pro.php" \
  --data-urlencode "salt=e9c84f1b…"
# NOTE: an error here is serialize()-encoded, not JSON.

Query licenses in PHP (inside WordPress)

$stats = lmfwc_get_user_stats( 99 );
printf( "%d active of %d total\n", $stats['active'], $stats['total'] );

Query with WP-CLI

wp license-manager user-stats 99 --format=json --user=admin

07 Deeper reference

The full, authoritative contract lives in the plugin's own documentation. Every exact parameter, response shape, error code and hook signature is specified and test-pinned there.

Links point to the documentation shipped with the plugin. Final URLs are set at build time.