← DPM DOCUMENTATION / DEVELOPER LICENSING API

DIGITAL PRODUCT MANAGER PRO

Getting Started

Connect external software to DPM's licensing and protected update infrastructure using the experimental Developer Licensing API.

The Developer Licensing API allows developers to connect external software to the licensing system managed by Digital Product Manager Pro.

It provides endpoints for licence activation, validation, deactivation and update checks. DPM remains responsible for generating and managing licences, activation limits, entitlement and protected update packages, while your external application is responsible for implementing the client-side integration.

The Developer Licensing API is experimental. It is intended for developers who are comfortable building, testing and maintaining their own licensing and update client.

1. When to Use the Developer API

Use the Developer Licensing API when you want DPM to manage licences for software that cannot use DPM's automatic WordPress plugin or theme integration.

For an installable WordPress plugin or theme, use Licensed WordPress Plugin or Licensed WordPress Theme instead. Those product types allow DPM to create the licensed WordPress package and provide the native WordPress licensing and private-update integration automatically.

For other software, create a Standard Digital Download and enable the Developer Licensing API in the product settings.

Developer Licensing API settings and endpoints in Digital Product Manager Pro

2. Enable the API for a Product

Open the product under Digital Products > Products and choose Standard Digital Download.

Enable Developer Licensing API in the product settings. DPM assigns and manages the product's Licensing Identity and makes the licensing endpoints available for your application to use.

Your application must know the DPM store URL, the product's licensing identity and the customer's licence key. It should also provide its own site or installation identity where appropriate.

3. API Endpoints

The Developer Licensing API provides four primary REST endpoints:

  • /wp-json/dpm/v1/license/activate — activate a licence for an installation.
  • /wp-json/dpm/v1/license/check — validate the current licence and entitlement state.
  • /wp-json/dpm/v1/license/deactivate — release an existing activation.
  • /wp-json/dpm/v1/update/check — check whether an entitled update is available.

These endpoints are hosted by the WordPress site running DPM.

4. Request Fields

The core request fields are:

  • license_key — the customer's DPM licence key.
  • product_id — the permanent DPM licensing identity for the product.
  • site_url — the site, installation or client location associated with the request.

DPM also supports useful client context such as instance_id and current_version. Providing a stable installation identifier is recommended when your application can support one.

5. Activate a Licence

Call /license/activate when the customer enters a licence key and asks your application to activate it.

DPM validates the licence, product, entitlement and activation allowance. A successful response confirms that the licence is valid for the requested product and records the activation.

Your application should store enough local state to identify the activation on future checks and deactivation requests. Do not treat a locally stored value as the authority for licence validity; DPM remains the licensing authority.

6. Check a Licence

Use /license/check to validate an existing licence and determine its current state.

Your client should handle valid, expired, revoked and invalid responses appropriately. An expired or revoked licence can prevent future updates or new activations, but DPM's licensing philosophy is not to remotely destroy or cripple already-installed software.

How your external application presents licence status to the customer is part of your own integration.

7. Deactivate a Licence

Call /license/deactivate when the customer deliberately disconnects an installation or moves the licence to another machine or site.

A successful deactivation releases that activation from the licence's activation allowance. Your application should then clear the corresponding local activation state.

8. Check for Updates

Send the installed current_version to /update/check to ask DPM whether a newer entitled version is available.

When an update is available and the licence has permission to receive it, DPM can return the new version information together with a short-lived protected package URL.

Your application is responsible for comparing versions, presenting the update to the user, downloading the package, verifying that the download completed correctly, installing it safely and handling any rollback or restart requirements.

9. Protected Package Delivery

Update package URLs returned by DPM are temporary and signed. They are intended to provide authorised delivery without exposing a permanent public download URL for the commercial product.

Your client should request a fresh update response when it needs a package rather than storing the signed package URL indefinitely.

10. Security and Validation

The API endpoint addresses and request field names are not secrets. Security comes from strong licence keys, server-side validation, activation and entitlement checks, product binding and short-lived signed package delivery.

Do not place private DPM server credentials or other merchant secrets inside distributed client software. Treat all client-side software as inspectable by the end user.

Your integration should also handle failed requests, unavailable networks and unexpected responses safely rather than assuming every API call will succeed.

11. Licence Activity

Developer API requests can appear in DPM's Licence Activity & Intelligence journal. This gives you visibility into licence checks, activations, domains, versions and results while investigating customer support or licensing issues.

Review indicators are informational and intended for human investigation. They do not automatically revoke a licence or damage the customer's software.

12. Developer Responsibility and Support

DPM provides the server-side licensing infrastructure, licence management and protected update delivery. The external application integration remains the responsibility of the software developer.

This includes implementing and testing activation, licence checks, deactivation, update checking, downloading, installation, error handling, rollback and any required restart process.

External API integration, testing, maintenance and application-specific update behaviour are not covered by DPM technical support.

13. Test Before Release

Before distributing an API-connected product, test the complete lifecycle using a test customer and licence:

  • Activate a valid licence.
  • Confirm the licence check returns the expected state.
  • Verify activation limits are enforced.
  • Deactivate and confirm the activation is released.
  • Publish a newer test version and confirm update detection.
  • Download the protected package using the returned signed URL.
  • Test expired, revoked and invalid licence responses.
  • Confirm your application fails safely when the DPM store cannot be reached.

You're Ready

Once the complete lifecycle has been tested, DPM can act as the licensing and protected-delivery backend for your external software while your application controls the customer-facing integration.

For WordPress plugins and installable themes, use Automatic WordPress Licensing instead whenever possible. It removes most of this client-side integration work.

DOCUMENTATION
Digital Product Manager Pro for Divi
SIMPLE | POWERFUL | DELICIOUS.