Cryptlex Web API

The Cryptlex Web API gives you programmatic access to everything in your Cryptlex account: licenses, activations, users, releases, and more. It follows RESTful design principles:

1. All requests must be made over HTTPS.
2. All URLs are resource-oriented, so you can navigate the API predictably.
3. Responses consistently use JSON format, even for error messages.
4. Standard HTTP status codes indicate success or failure, and detailed error messages help you identify and resolve issues.

Base URL

The base URL is https://api.cryptlex.com, or https://api.eu.cryptlex.com for accounts in the EU data region.

Versioning

All API requests are versioned using the major version prefixed by a 'v' in the URL, e.g. v1, v2, v3. The latest supported version is v3 (3.x.x).

We follow Semantic Versioning. Given a version number MAJOR.MINOR.PATCH, the version is incremented in the following manner:

• MAJOR version when we make incompatible or breaking API changes,
• MINOR version when we add functionality in a backward-compatible manner, and
• PATCH version when we make backward-compatible bug fixes.

When we introduce breaking changes to the API, we release a new versioned URL endpoint. Refer to the changelog for changes made to date.

Errors

The API uses standard HTTP status codes to indicate the success or failure of the API call. All errors contain 4xx or 5xx status codes in the response header. The body of the response contains the error message in the following format, where the code property is included only when a specific error code applies:

{
    "message": "Email address is already taken!",
    "code": "DUPLICATE_FIELD_VALUE"
}

Rate limiting

A single IP address can make a maximum burst of 50 requests per 5-second window, regardless of authentication. If we observe patterns of abuse, the IP address may be temporarily or permanently blacklisted.

Rate limit status can be checked in the returned HTTP headers of any API request:

Pagination

List endpoints are paginated using the page and limit query parameters. limit must be a number between 1 and 100.

GET /v3/licenses?page=2&limit=100

The total number of records matching the query is returned in the Pagination-Count response header, so you can read the total count from a single request without walking the pages.

Sorting

Use the sort query parameter with a property name prefixed by + for ascending or - for descending order. Multiple sort fields can be combined, separated by |, and are applied in order.

GET /v3/licenses?sort=-createdAt

Filtering

List endpoints support filtering on their resource's properties using query parameters named after the property. The filterable properties for each endpoint are listed on its reference page. A parameter without an operator matches values exactly; append an operator in brackets for other comparisons:

Examples:

GET /v3/licenses?user.email[cn]=@example.com
GET /v3/licenses?key[in]=KEY1,KEY2,KEY3
GET /v3/licenses?createdAt[gt]=2026-01-01T00:00:00Z&createdAt[lt]=2026-02-01T00:00:00Z
GET /v3/licenses?metadata.key=plan&metadata.value=pro
GET /v3/licenses?totalActivations[gte]=5

Filters on different parameters combine with AND semantics.

Searching

Use the search query parameter, where available, to match a search string across the resource's commonly searched fields (up to 256 characters):

GET /v3/users?search=alice

Related resources

Resources in the API relate to one another. For example, a license relates to a user, a reseller, and an organization. By default, a response contains only the requested resource, along with the IDs of its related resources (such as userId). A related resource can be fetched separately using its ID, e.g. GET /v3/users/{id}.

Use the include query parameter, where available, to embed full related resources in a single request. For example, to return each license with its full user object:

GET /v3/licenses?include=user

The include parameter accepts a comma-separated list of related resources. Including more resources may result in larger responses and longer response times.

GET /v3/licenses?include=user,reseller

Your access token must have read permission for every related resource you include, e.g. include=user requires the user:read permission. Requesting a resource you are not authorized to read fails with a 403 Forbidden response. Providing an unsupported include value fails with a 400 Bad Request response.