Zentitle2 Management API (2025-10-10:v1.0.1624)

This is the documentation for Zentitle2 Software Licensing Platform for SaaS and On-Premise applications.

Please provide feedback to your account manager on things you like and things you'd like to see.

Zentitle2 Management API uses OAuth2 over https to manage authentication and authorization.

OAuth2 is an open standard for authorization that enables applications to securely access resources from other apps or services. We use client_credentials flow in the API.

In the client credentials flow, the app sends a request to the authorization server's token endpoint with its client ID and secret, which are used to authenticate the app. If the request is successful, the authorization server returns an access token, which the app can use to access protected resources on the resource server.

The client credentials flow is typically used by server-side apps or apps that run in a trusted environment, such as a secure server or device. It allows these apps to access protected resources on behalf of themselves, rather than on behalf of a user. This grant type is not suitable for browser-based apps or mobile apps, as it does not involve user interaction and does not provide a way for users to grant access to their protected resources.

Here is an example of how to generate client credentials for OAuth2:

1. Register your application in the Zentitle2 administration site in the "API Credentials" section.

2. During the registration process, the authorization server will provide you with a client secret for your provided client ID. These are unique, secret values that identify your app and are used to authenticate your requests to the authorization server.

3. In order to use the client credentials grant type, your app must be able to securely store the client ID and secret. These values should never be shared or exposed to anyone outside of your app, as they provide access to the authorization server on your app's behalf.

4. Once you have securely stored the client ID and secret, you can begin making requests to the authorization server's token endpoint using the client credentials grant type. This typically involves sending a POST request to the token endpoint, with the client ID and secret provided in the request body.

5. You will find the token endpoint URL in the Zentitle2 administration site in the "API Credentials" section. Please be aware that the token endpoint URL provided in the UI is the main URL to the IDP for your account. To make a request to the token endpoint, you will need to append /protocol/openid-connect/token to the URL.

6. If the request is successful, the authorization server will return an access token, which can be used to access protected resources on the resource server. The access token may also include a refresh token, which can be used to obtain a new access token when the original one expires.

Here is an example code in JavaScript that gets the access token:

var body = 'grant_type=client_credentials'
            + '&client_id=' + clientId
            + '&client_secret=' + clientSecret;
pm.sendRequest({
    url: oauth_url + '/protocol/openid-connect/token',
    method: 'POST',
    header: {
        'Content-Type': 'application/x-www-form-urlencoded',
        'Accept': 'application/json'
    },
    body: {
        mode: 'raw',
        raw: body
    }
}, function (err, res) {
    var response = res.json();
    environment.set("access_token", response.access_token);
    environment.set("token_time", Date.now() + response.expires_in * 1000);
});

Access token should be sent with every API request in the Authorization header as:

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI...

Whenever the Authorization section for an endpoint contains more than one role in the list, it means that any of those roles is sufficient to access this endpoint.

API requires one more header to be set with Id of your Zentitle2 tenant, for example:

N-TenantId: t_KRwhRp1yl0_9gsZjE5Yjaw

The Zentitle2 API adheres to the ISO 8601 standard for date and time formatting. For instance, "2021-12-31T23:59:59Z" signifies the final second of the year 2021 in the UTC time zone. The backend systems of Zentitle2 function in UTC, and as such, all DateTime fields returned by the API are also in UTC. To enhance the usability of our API, we accept datetime values in several formats:

• 2021-12-31T23:59:59Z - UTC time
• 2021-12-31T23:59:59 - dates without timezone information are assumed to be UTC time
• 2021-12-31T23:59:59+01:00 - time with timezone information

It's very easy to setup Postman to use with Zentitle2 Management API.

1. Download OpenAPI specification (top of this page)
2. Import downloaded file to Postman
3. Select "No Auth" in the Auth tab (auth will be done using pre-request script).
4. Add following script in the pre-request script tab:

pm.environment.set("baseUrl", pm.environment.get("orionApiUrl"));

var setAuthHeaders = () => {
    pm.request.headers.add({key: 'N-TenantId', value: pm.environment.get("tenantId") });
    pm.request.headers.add({key: 'Authorization', value: pm.environment.get("oauth_token") });
};

if (pm.environment.get("token_time") && pm.environment.get("token_time") > Date.now()) {
    setAuthHeaders();
    return;
}

var body = 'grant_type=client_credentials'
    + '&client_id=' + pm.environment.get("clientId")
    + '&client_secret=' + pm.environment.get("clientSecret");
pm.sendRequest({
    url: pm.environment.get("oauth_url"),
    method: 'POST',
    header: {
        'Content-Type': 'application/x-www-form-urlencoded',
        'Accept': 'application/json'
    },
    body: {
        mode: 'raw',
        raw: body
    }
}, function (err, res) {
    var response = res.json();
    pm.environment.set("oauth_token", 'Bearer ' + response.access_token);
    pm.environment.set("token_time", Date.now() + response.expires_in * 1000);

    setAuthHeaders();
});

5. Set up a new Postman Environment using the JSON configuration file downloaded from Zentitle2.

   • Start by launching Zentitle 2 and navigating to the 'Account > API Credentials' section.
   • Locate the 'Management API Clients' box and click on the 'Add API Client' button.
   • Provide a unique Client ID and remember to save it.
   • To download your configuration file, click on the 'Download Postman environment configuration' button.
   • Once you have your configuration file, open the Postman application.
   • In the left sidebar of the Postman application, click on the 'Environments' tab.
   • Inside the Environments tab, find and click on the 'Import' button.
   • A dialog box will appear. Click on 'files' and navigate to the location where your JSON file is stored.
   • Select the JSON file that contains the Postman environment variables and click on 'Open'.
   • Postman will import the environment variables from the JSON file. These variables will be visible in the 'Environments' section in the sidebar.
   • To use the imported environment, select it from the environment dropdown. This dropdown is located in the top right corner of the Postman application.

In case of an error, API returns error status code along with ApiError object if applicable.

Please see API Versioning documentation for more information about our versioning strategy and how to select an API version.

2025-10-10

Entitlement creation

• POST /api/v1/entitlements removed and replaced by POST /api/v1/entitlements/groups (CreateEntitlementGroupApiRequest).
  • New request supports multiple SKUs via skus[] (required); optional customerId, orderRefId, and activationCode (auto-generated if omitted).
  • Extend an existing group with additional SKUs using POST /api/v1/entitlements/groups/{entitlementGroupId}/extend (ExtendEntitlementGroupApiRequest).

Add support for entitlement group license files

Manage entitlement group license files via:

• GET /api/v1/entitlements/groups/{entitlementGroupId}/license-file (download the current file)
• POST /api/v1/entitlements/groups/{entitlementGroupId}/license-file (regenerate/upload)
• DELETE /api/v1/entitlements/groups/{entitlementGroupId}/license-file (remove)

Activation lifecycle updates

• POST /api/v1/entitlements/activations now returns ActivationStateModel and can return 200 when reusing an existing activation.
  • Previously always returned 201 with ActivationModel.
• PATCH /api/v1/entitlements/activations (refresh) now returns ActivationStateModel.
  • Previously returned ActivationModel.
• PATCH /api/v1/entitlements/activations/{activationId}/features/checkout and PATCH /api/v1/entitlements/activations/{activationId}/features/return now return 200 with ActivationFeatureModel.
  • Previously returned 204 with an empty body.
• DELETE /api/v1/entitlements/activations/{activationId} no longer accepts force query parameter (operation always honors system safeguards).
• DELETE /api/v1/entitlements/activations/offline/deactivate replaced with POST /api/v1/entitlements/activations/offline/deactivate

Offerings

• New: PATCH /api/v1/offerings/{offeringId} (partial updates) using PatchOfferingApiRequest (includes usageResetSchedule). PUT remains for full replacement.
• GET /api/v1/offerings list response changed from PaginatedListOfOfferingModel to PaginatedListOfOfferingListModel (leaner listing shape; use GET by id for full details).

End users → Contacts (profiles) and credentials

• Contacts fully replace legacy end users. A contact captures the person’s profile and always exists even if the person has no credentials. Credentials are now a separate, optional resource that can be attached to a contact.
• Profile endpoint mappings:
  • POST /api/v1/customers/{customerId}/users → POST /api/v1/customers/{customerId}/contacts (CreateCustomerContactApiRequest → CustomerContactModel)
  • GET /api/v1/customers/{customerId}/users → GET /api/v1/customers/{customerId}/contacts (PaginatedList; supports pageNumber, pageSize)
  • GET /api/v1/customers/{customerId}/users/{userId} → GET /api/v1/customers/{customerId}/contacts/{contactId} (CustomerContactModel)
  • PUT /api/v1/customers/{customerId}/users/{userId} → PUT /api/v1/customers/{customerId}/contacts/{contactId} (UpdateCustomerContactApiRequest)
• Credential endpoint mappings (only required when the contact can sign in):
  • GET /api/v1/customers/{customerId}/users/{userId} (CustomerUserModel.authentication) → GET /api/v1/customers/{customerId}/contacts/{contactId}/credentials (GetCredentialsModel.authentication)
  • PUT /api/v1/customers/{customerId}/users/{userId} (update embedded authentication) → PATCH /api/v1/customers/{customerId}/contacts/{contactId}/credentials (UpdateCredentialsApiRequest)
  • POST /api/v1/customers/{customerId}/users/{userId}/password/action → POST /api/v1/customers/{customerId}/contacts/{contactId}/credentials/password/action (ContactPasswordActionApiRequest)
• Authorized Users (Entitlement Group) endpoints maps to contacts as follows:
  • GET /api/v1/entitlements/groups/{entitlementGroupId}/authorized-users → GET /api/v1/entitlements/groups/{entitlementGroupId}/authorized-contacts
  • PATCH /api/v1/entitlements/groups/{entitlementGroupId}/authorized-users/add → POST /api/v1/entitlements/groups/{entitlementGroupId}/authorized-contacts
  • PATCH /api/v1/entitlements/groups/{entitlementGroupId}/authorized-users/remove → DELETE /api/v1/entitlements/groups/{entitlementGroupId}/authorized-contacts/{contactId}
• Contacts introduce richer profile fields (e.g., title, contactRefId, isKeyContact, location) while credential management is isolated to:
  • GET /api/v1/customers/{customerId}/contacts/{contactId}/credentials
  • PATCH /api/v1/customers/{customerId}/contacts/{contactId}/credentials
  • POST /api/v1/customers/{customerId}/contacts/{contactId}/credentials/password/action

Model changes — highlights

• Activation and features
  • ActivateEntitlementApiRequest: added editionId; removed activationCode; activationCredentials is now required.
  • ActivationStateModel / ActivationModel: removed lingerExpiry.
  • ActivationFeatureModel: added currentUsagePeriodStart, nextUsagePeriodStart.
• Entitlement groups
  • EntitlementGroupModel: added licenseFile; customer now references EntitlementGroupCustomerModel (was CustomerModel).
  • CreateEntitlementGroupApiRequest: properties customerId, skus[] (required), activationCode, orderRefId.
  • ExtendEntitlementGroupApiRequest: property skus[] (required).
• Entitlements and products
  • EntitlementModel: added usageResetSchedule; removed lingerPeriod; overdraftSeatLimit now uses OverdraftLimitModel (was OverdraftSeatLimitModel); product now uses EntitlementProductModel (was ProductModel).
  • EntitlementFeatureModel and EntitlementOffering[Feature|Model]: an overdraft type moved from OverdraftSeatLimit* to OverdraftLimit*.
  • OfferingApiRequest: added usageResetSchedule; an overdraft type moved to OverdraftLimitApiRequest.
  • UpdateFeature / UpdateFeatureApiRequest / UpdateProductFeatureApiRequest: property overdraftLimit now uses OverdraftLimitApiRequest (was OverdraftSeatLimitApiRequest).
  • UpdateProductApiRequest: removed required lingerPeriod.
• EUP settings
  • EupSettingsModel / UpdateEupSettingsApiRequest: added showActivationCodes, showEntitlementGroups, showUserManagement; showActivationsGraph now uses EupFeatureAccess; url is no longer required in update.
• Local License Servers
  • LocalLicenseServerEntitlementModel: embeds LocalLicenseServerEntitlementDetailModel and LocalLicenseServerEntitlementGroupModel for richer detail.

2024-01-01

Initial release