1. Home
  2. Docs
  3. WooCommerce License Keys
  4. API Implementation
  5. Build A Client

Build A Client

To implement and integrate the API with your products, you will need a client.

The term “Client“, comes from the “Server Client” software model; where the license keys API, hosted at your WordPress (WooCommerce), acts as the server, and your products act as a client. The API provides all the licensing functionality needed to implement DRM (Digital rights management) within your products.

Illustration provided by Orosk.com

The client

Our plugin provides all the “Server” functionality needed through the API.

For the “Client” side, you can take a look at the list of available clients developed by us or 3rd party; you can build it yourself if there is no client for the coding language or framework used by your products.

How to build an API client?

Requirements

  • Your product will need internet connectivity to be able to interact with the licensing API.
  • Your product’s coding language will need to be able to make a basic HTTP request.

The licensing flow

The API provides 3 essential endpoints (activation, validations, and deactivation), these will cover all the DRM functionality needed to maintain the validity of your products.

The next 3 steps, will explain each endpoint’s purpose and when should each be used.

  1. The first interaction between the API and the product should be through the activation endpoint. This will allow a product to be activated and to enable licensed features.
    Expected flow:
    1. The customer enters a license key code through a form in your product.
    2. The product sends an HTTP request to the API’s activation endpoint.
    3. The API validates the code. When the code is valid, the API registers an activation (activates the license key) and returns a valid response to the product. When the code is invalid, the API returns a failed response.
    4. The product receives and processes the response. When the response is successful, the product saves the license details returned by the API (for later validation) and activates the licensing features of the product. When the response is a failure, the product indicates this to its user and expects a new code to be entered.
  2. Once a product is activated, and depending on the license settings, the product may want to validate the license key code periodically to either check for updates (through the downloadable data appended to the API’s response) or to prevent piracy. This is done through the API’s validation endpoint.
    Expected flow:
    1. Periodically, the product sends an HTTP request to the API’s validation endpoint with the license key code used for activation.
    2. The API validates the code and returns a response with the results.
    3. The product receives and processes the response. When the response is successful, the product continues to be activated. When the response is a failure, the product turns off licensed features and reports this to its user.
  3. The API’s deactivation endpoint if the product’s user needs to deactivate the activated product (by any needs).
    Expected flow:
    1. The product’s user clicks a deactivation button.
    2. The product sends an HTTP request to the API’s deactivation endpoint with the activation data.
    3. The API validates the request, deactivates the activation registered and returns a response with the results. The API returns a valid response when if the deactivation was possible.
    4. The product receives and processes the response. When the response is successful, the product deactivates and disables licensed features. When the response is a failure, the product turns reports to the user.

Handlers

The “Server” side of our plugin, the API, can to be mounted on different handlers. Read the API basics to learn more about each handler’s differences and how to use them.

Depending on the method used, the endpoint’s parameters should be sent as a query string (GET) or as post data (POST).

The following, are simple comparison tables that can be used to determine which handler would suit you better:

Handler: WP Ajax

METHODSGET, POST
CORS OVERRIDEYes (Read more)
ENDPOINTSThe endpoints are determined by the “action” request parameter. (See each endpoint documentation).
RESPONSEJSON
WORDPRESSRuns on WordPress admin and supports with REST API turned off, or versions before 4.7.

Handler: WordPress Rest API

METHODSPOST
CORS OVERRIDENo
ENDPOINTS The endpoints are part of the request URL. (Read this handler’s documentation to learn more)
RESPONSE JSON
WORDPRESS WordPress version 4.7 of greater with REST API tuned on.

Was this article helpful to you? Yes No