Develop

Integrating Oclavex means calling its REST API — directly, or through a client SDK.

• Authentication — the two credential models: client credentials for your backend, activation code + fingerprint for the runtime — and which endpoints take which.
• .NET SDK — install and configure the license consumer, then follow the series: activate, enforce entitlements, report usage, work offline and fingerprint devices. The feature blocks & architecture page maps how the packages assemble from a mandatory core plus optional blocks.
• Using the REST API — URL areas, pagination, update semantics, retries and the error contract; call everything directly in any language.
• Offline (air-gapped) activation — activate and keep licensed machines that never connect, via signed files.
• Receiving webhooks — verify signatures, answer the registration challenge, survive retries and secret rotation.
• Hardware keys (YubiKey) — bind a license to a YubiKey, so it works on any computer the key is plugged into and on no other.

Tip

A client SDK is a convenience wrapper around the REST API — it does nothing you can’t do over REST. For C and C++, the SDK core ships as a native shared library, liboclavex, with a C header (oclavex.h) and a header-only C++ RAII wrapper — covering validation, the encrypted license cache, entitlements, usage metering, online activation/refresh/check-in/release, and offline response/receipt import. The library is the .NET consumer core compiled with Native AOT behind a C ABI. It lives in the SDK repository under dotnet/capi and cpp/, prebuilt for each platform and downloadable from the repository’s releases. Any other language with an HTTP client and a JWT library can implement the same loop: activate, cache, validate, report. The API is the full contract.