Test your Direct Entitlement API V2

Using the Postman tools is an easy way to test your direct entitlement implementation with API V2. You can download this tool for free from http://www.getpostman.com.

After you install it, click the Import collection button which is close to the center of your screen. Then, add the V2 collection that you can download from the sample files.

Click No environment on the right of the screen, select Manage Environments, and add the Service URL that you want to test.

In the Manage Environments tab, enter the following:

• Key: baseURL
  
• Value: the URL of your service

This step makes the verification process much easier, as you don't have to enter the path of your Service URL manually each time you make API calls. However, you can still do that by selecting No Environment, and manually fill in the necessary information.

Now, you are ready to test the calls for the API V2.

Click Params and specify the appId of the application. Also specify any other optional parameters that your implementation requires.

Edit the XML body of the POST request to contain the emailAddress/user name and password of a test user that you have created in your database.

Note: emailAddress is the name of the field, but can be any string format your service is designed to accept.

If this step is done correctly, the result is an authToken, as follows;

<result httpResponseCode="200">

<authToken>your_AuthToken</authToken>

</result>

The correct answer should always be a 200 ResponseCode with an authToken string, like the example above.

If the response is different from the 200, then something isn’t working properly.

For example, a common error is a 401. This error indicates an unauthorized user. So, double-check the emailAddress and password values that were passed and make sure that the user is entitled in the database.

Save the authToken that you have received in a text editor for additional testing.

At this step, specify the appId of the application, the authToken from the previous step and any of the other optional parameters that your implementation requires.

If the server returns a 200, the body also contains an authToken. Depending on your implementation, it could be different from the original. If it's different, note it i to use it with the next calls.

As in the previous step, a 200 response validates that everything is working correctly.

Click the Params button, specify the appId and the authToken, as well as any other required parameters that your implementation requires, including folio productId and coverDate values if necessary as raw request body data, then click Send.

This call gives you a list of productIds representing the folios the user is entitled to.

If the response code is 200, it means that the call is working and the issues which the user is entitled to should be listed as productId elements. An empty entitlements list means that the user is not entitled to any folios. This can be due to a misconfiguration of the user's entitlements on the server, or missing data in the request body needed to validate their entitlement.

A 401 error in the Entitlements call, could indicate that the authToken is not valid, so it needs to be checked.

In this article, you have learned how to test your Direct Entitlement Server with Postman.

If you would like more information regarding Direct Entitlement, check out the documentation below:

• Direct Entitlement
• Entitlement Service