Skip to main content
This is the core public API your application calls at runtime to check whether a license is currently valid. You supply the license ID, the product the license should be associated with, and the hardware identifier of the machine requesting access. Avalex runs a sequence of checks and returns a single valid boolean — no authentication or API key is required, making it straightforward to integrate directly into your product’s startup or entitlement logic.
This is a public endpoint. No authentication header is required to call it.
This endpoint is rate limited to 30 requests per minute per IP address. Exceeding this limit returns a 429 Too Many Requests response. Design your integration to avoid polling this endpoint in tight loops; see the caching tip below.

Request Body

string
required
The unique identifier of the license to validate, for example LIC-9981-A2.
string
required
The product identifier that the license must be associated with. If the license belongs to a different product, validation will return valid: false.
string
required
The hardware identifier of the machine making the validation request. Avalex uses this value to enforce per-seat HWID binding on licenses that have a hardware slot limit configured.

Request Example

Response — 200 OK

boolean
true if the license passes all validation checks; false if any single check fails. See Validation Logic below for the full sequence of checks performed.

Validation Logic

Avalex evaluates the following checks in order. If any check fails, the response is {"valid": false} and no further checks are performed. Steps 3 and 4 only consume a slot on the first time a new IP address or hardware ID is seen. Subsequent requests from an already-bound IP or HWID do not consume additional slots.

Error Responses

Notes

A valid: false response is a legitimate validation outcome, not an error condition. Your application should explicitly handle both true and false values rather than treating only false as an unexpected state.
All validation attempts — both successful and failed — are recorded by Avalex and are visible in the Admin Portal under Validation Attempts. Use this log to audit usage patterns or investigate unexpected failures.
To support offline usage and reduce pressure on the rate limit, cache the last valid: true response locally with a grace period of 24–72 hours. If Avalex is unreachable, your application can fall back to the cached result within the grace window before requiring a fresh check.