Key-Based Activate and Deactivate #
These routes were introduced in v1.2.0 and updated in v2.0.0 to require product_id.
The key-based endpoints (POST /licenses/activate and POST /licenses/deactivate) are the recommended way to implement activation in your client software. They accept a license key directly instead of requiring you to first look up the internal license ID.
Why Key-Based Routes? #
In the original API design (v1.0.0), activating a site required:
- First calling
GET /licenses?license_key=XXXXto retrieve the internal license ID - Then calling
POST /licenses/{id}/activatewith the ID
The v1.2.0 key-based routes eliminate the lookup step. Client software only ever needs to store the license key — never an internal ID.
Minimum Integration (v2.0.0) #
# Activate
POST /wp-json/dmsilm/v1/licenses/activate
{
"license_key": "DMSI-XXXX-XXXX-XXXX-XXXX",
"site_url": "https://customer-site.com",
"product_id": 42
}
# Deactivate
POST /wp-json/dmsilm/v1/licenses/deactivate
{
"license_key": "DMSI-XXXX-XXXX-XXXX-XXXX",
"site_url": "https://customer-site.com",
"product_id": 42
}Both requests include product_id (required since v2.0.0). The product_id value is your DDLS product’s internal ID (visible in DDLS > Products).
Optional: Capture Customer Email on Activation #
New in v2.0.0, you can optionally pass customer_email in the activate request:
POST /wp-json/dmsilm/v1/licenses/activate
{
"license_key": "DMSI-XXXX-XXXX-XXXX-XXXX",
"site_url": "https://customer-site.com",
"product_id": 42,
"customer_email": "user@example.com"
}If the customer has no email on record, the email is stored. The response includes an email_notice field:
{
"success": true,
"activation_id": 123,
"email_notice": "Customer email captured and stored. The customer may request removal."
}The email_notice field only appears when an email was actually captured. If no email was passed, or if the customer already had an email on record, the field is absent from the response.
