REST API Overview #
The DMSI Update Server exposes a REST API that client software calls to check for updates and download new versions.
API Namespace #
All endpoints are under the namespace: dmsilm/v1
Base path: /wp-json/dmsilm/v1/updates/
Available Endpoints #
| Method | Endpoint | Purpose |
|---|---|---|
| POST | /updates/check | Check if an update is available for a specific product and license |
| POST | /updates/info | Get metadata for a specific version |
| POST | /updates/versions | List available versions for a product |
| GET | /updates/status | Server health check (no authentication required) |
| GET | /dmsilm-download/?token=... | Download a file (custom rewrite rule, not under REST namespace) |
Authentication #
All endpoints except /status authenticate via license key validation inside the endpoint handler. There is no HTTP authentication header, API key, or OAuth token.
Each request must include the customer's license_key in the POST body. The API validates the key against the DDLS license database and returns an error if:
- The key does not exist
- The license is expired, suspended, or cancelled
- The product does not match the license
Rate Limiting #
Update check requests are rate-limited per license to the configured limit (default: 100 requests/hour). Rate-limited requests receive HTTP 429 with an error response.
Response Format #
All endpoints return JSON. Success responses follow this pattern:
{
"update_available": true,
"version": "2.0.0",
...endpoint-specific fields...
}
Error responses:
{
"code": "invalid_license",
"message": "License key is not valid.",
"data": {"status": 400}
}
Caching #
Update check results are cached as WP transients for the configured cache duration (default: 15 minutes). The cache key is based on product_id + current_version + channel. If two licenses on the same product and version check within the cache window, both get the cached result.
Important: license_id is excluded from the cache key. During staged rollouts below 100%, different licenses checking within the same cache window will receive the same cached response regardless of their individual rollout bucket. This means rollout boundaries are approximate, not exact — a license that would normally be excluded from a 25% rollout may receive an update response cached from an included license. For tighter rollout boundary control, reduce the cache duration or set rollout to 100%.