> For the complete documentation index, see [llms.txt](https://docs.licensespring.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.licensespring.com/common-scenarios/glossary/postman-collections/license-api-collection.md).
# License API Collection
### Base URL and Authentication Requirements
#### License API Base URL
All License API requests must use the License API domain: [https://api.licensespring.com](https://api.licensespring.com/)
Do not use [https://saas.licensespring.com](https://saas.licensespring.com/) for License API requests. The saas domain is reserved for the Management API.
#### Required Authentication Keys
The License API supports the following authentication methods:
* apiKey
* sharedKey
Both keys must be configured in the environment for Shared Key authentication workflows.
#### OAuth Authentication (optional)
If using the OAuth version of the License API, the following credentials are required:
* client\_id
* client\_secret
The OAuth collection will obtain an access token using these values and automatically apply it to subsequent requests.
### License API Environment Variables
Used by **License API** and **License API – OAuth** collections.
| Variable | Description |
| -------------------------------------------- | ---------------------------------------------------------------------- |
| default\_product\_code | Product code associated with the license. |
| default\_license\_key | License key used for activation/validation. |
| default\_hardware\_id | Hardware ID for binding and validation. |
| default\_feature\_code | Feature identifier for license feature operations. |
| default\_username / default\_password | Used for user-based licenses. |
| default\_customer\_account\_code | Customer account reference used by some endpoints. |
| default\_license\_id / default\_bundle\_code | Identifiers for specific license or bundle operations. |
| request | Required for offline flows. Must be set to activation or deactivation. |
Values can be set manually or retrieved through License API requests or the LicenseSpring UI. Please populate fields based on your use case for each endpoint.
### How the Collections Work
#### License api collection
Purpose: To interact with licensing endpoints using either **API Key/Shared Key** authentication.
Requirements: Most requests require:
* default\_product\_code
* default\_license\_key
* default\_hardware\_id
Headers such as **Date** and **Authorization** are generated automatically.
#### License api - Oauth collection
Purpose: To interact with License API endpoints using OAuth 2.0 authentication.
Usage: Set **client\_id** and **client\_secret** in the environment from our vendor platform. The collection obtains an access token automatically and uses it for all subsequent licensing requests.
### Manual variable adjustment (optional)
If you want to test with a specific license key, hardware ID, feature code, or bundle ID, you may replace the corresponding environment variable manually.
{% stepper %}
{% step %}
### Open the LicenseSpring platform UI
Navigate to the LicenseSpring platform where your product and license information is available.
{% endstep %}
{% step %}
### Copy the license key or product code you want to test
Locate the specific license or product and copy the relevant values.
{% endstep %}
{% step %}
### Paste it into the relevant environment variable
Update variables such as default\_license\_key, default\_product\_code, etc., in your collection environment.
{% endstep %}
{% step %}
### Re-run the desired request
Execute the request in the collection to test with the updated values.
{% endstep %}
{% endstepper %}
You may also temporarily place literal values directly into the request body. Every needed variable can be found and created through our vendor platform.
### Offline Licensing Notes
Some License API workflows require special handling:
* Offline activation
* Offline deactivation
* v2 offline schema
In these cases, the variable request must be set to one of the following:
activation
deactivation
Ensure the final JSON object in the body does **not** contain trailing commas when uncommenting optional parameters.
Examples of available offline requests v1 used for activation/deactivation:
* `{{offline_request_file}}` -> used for key-based license
* `{{offline_request_file_bundle}}` -> used for key-based bundle licenses
* `{{offline_request_file_user}}` -> used for user-based licenses
* `{{offline_request_file_user}}` -> can also be used for user-based licenses if **default\_product\_code** points to bundle\_code (set in the environment)
Examples of available offline requests v2 used for activation/deactivation:
* `{{offline_request_file_v2}}` -> key-based licenses — also can be used for bundle if **default\_product\_code** set to bundle\_code (set in the environment)
* `{{offline_request_file_v2_user}}` -> user-based licenses — also can be used for bundle if **default\_product\_code** set to bundle\_code (set in the environment)
### Data manipulation
For manual data manipulation, the same principles apply as with the Management API.
If any aspect is unclear, consult the [License API](/license-api/introduction.md) docs for each request.
Please check your company settings and under preferences tab you will see:
Some of the license api requests depends on the selected settings in order to work, so keep that in mind.
Remember to review any comments associated with each request. For instance, to enable the floating release functionality, you should edit the desired license, verify the floating cloud checkbox via the platform, and subsequently execute the request to ensure proper operation.
### Floating Release
Example Comment: Verify Floating Cloud Status on Desired License via Platform
Here's an example of how to perform this check using two different scenarios: license-based and user-based.
#### License-Based Verification
For license-based verification, use the following request body:
{% code title="License-based request body" %}
```json
{
"license_key": "{{activate}}",
"hardware_id": "{{hardware_id}}",
"product": "{{product_code}}"
}
```
{% endcode %}
#### User-Based Verification
For user-based verification, utilize the following request body:
{% code title="User-based request body" %}
```json
{
"hardware_id": "{{default_hardware_id}}",
"product": "{{default_product_code}}",
"username": "{{default_username}}",
"password": "{{default_password}}",
}
```
{% endcode %}
{% hint style="info" %}
Note: You can also use the same environment as on our management API with the provided data.
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.licensespring.com/common-scenarios/glossary/postman-collections/license-api-collection.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.