What is Web API?

Web API can be thought of as a channel that can be used to talk to Serial Key Manager from external applications. It contains a wide range of methods that will respond different information depending on input parameters. For example, these methods allow you to activate keys, generate new ones, get list of activated machines, and so much more. It’s always possible to talk to the Web API directly (more info), however, you will most likely use an existing API that simplifies that task. If you use an environment that is not supported at the moment, it is always possible to use the Web API right away, which makes Serial Key Manager a platform independent system.


Web API with SKGL Extension API

If you happen to be using .NET Framework, there is already a client API that will do most of the work for you. In the knowledge base, you are likely to find examples in either C# or VB.NET. However, there exists an API for Java users too, although it is currently in Beta. The API is called SKGL Extension API. In most cases, there is no need to write code as there are already pre-configured code examples that can be accessed by clicking on,

However, if you would not be able to find the code you are searching for, you can find the variables in two places:

Note, Web API 3 works slightly differently than Web API 2. In Web API 3, you will need to provide a variable called (Access) Token, which is a way to perform authentication (identify you) and authorization (check permission).

The token is specified in the AuthDetails (in SKGL Extension) – a parameter that all methods in the Web API 3 require.

Note further that, in contrast to Web API 2, Web API 3 gives you more permission. Therefore, you need ensure that you provide the correct permission to each access token. Please read more about it under Web API 3 Workflow.

You are always welcome to ask questions on the forum!

Web API 3 Workflow

As we already know, an access token provides you with different kinds of permissions to access various methods in the Web API 3. This means that anyone who has access to the access token can essentially do everything that the access token permits them to do. Therefore, it’s important to be very careful. Please ask us on the forum if you would need any guidelines. Because of this, we’ve listed some possible scenarios and the way they should be tackled.

Calling Web API from your Server – High Trust

If you are going to call Web API methods from your own server that your end user doesn’t have access to, it turns out to be very simple. You simply need to create an access token with access to methods that you need, and optionally set a product lock or feature lock.

Calling Web API from a Third Party Server – Normal Trust

Depending on the level of trust of the third party server, there are various ways to configure the access token. If you trust the third party as your own server, you could use the same strategy that was mentioned above. However, it is good ensure that the access tokens that you use with the third party are as restricted as possible. Here’re some examples:

  • (normal trust level) If you want to upgrade a license by adding a feature to a specific product, please ensure to provide a product lock and a feature lock. So, if you want to set feature1 to be true, you should insert that information into the access token. Note: since we don’t have any key lock, it means that the third party can potentially set feature1 to be true for all license keys in that product.
  • (low trust level) If you don’t want the third party to be able to access all your license keys in that product, but only some, you will need to implemented the method described in Calling Web API from a Client Application. This assumes that your end user already owns a license key that they will supply to the third party application to perform the necessary business logic.

Calling Web API from a Client Application – Low Trust

Note: We’ve upgraded all of the methods in the Web API so that you won’t need to request a special access token. This part of the article is kept as a reference only.

The problem that we want to solve in this section is the ability to be able to configure some sort of key lock that will limit access to all license keys. That is, only the person that has access to a license key will be granted permission to operations concerning that license key. For this to work, we will need to send two requests to SKM:

  1. A request that generates a new access token with permission limited to that license key.
  2. A request that performs the necessary business logic on that key.

In step 1, we will get an access token that has the key lock set to the particular license key. In step 2, we use that access token (as we would in the high/normal trust levels) to access functionality in the Web API. The process can be summarized as follows:

web api key lock

In the Web API, step 1 can be achieved by Key Lock. In SKGL Extension, there is similar method that is currently available in our master branch. To sum up, the only thing the Key Lock method does is to return a new access token with the same permission except for the key lock (which is set to a specific license key) and an expiration date (by default, 1 day). In additional, it will provide you with a KeyId (not the key string) so that you can identify the license keys in methods that do not support direct entering of license key strings.

Old API?

Before Web API 2 and Web API 3, there was a different way to talk to Serial Key Manager. It’s of course better to use the new version (see Discontinuing Web API 1.0, Important information). Right now, some posts refer to the old API. you can always tell that you are using the new API if request contain https://serialkeymanager.com/ext or when you use the newest version of SKGL Extension.

About The Author

Most Helpful User

Rate This Article

(197 out of 292 people found this article helpful)

Leave A Comment?