Overview

The NorthScope Web Services API exposes a single endpoint for developers to issue automated requests against the NorthScope system and receive information about the current state of the system. NorthScope exposes several Request Types (listed below), each accepting their own request information and returning their own request-specific response document. The endpoint is exposed at the same location as the NorthScope web application (will vary from environment to environment), in the services folder.

If your NorthScope installation is accessible at NorthScope.example.com, the endpoint would be located at: NorthScope.example.com/services/ActionCommand.svc/APIExecute

From a high level, the process flow is as follows:

Open

Anatomy of a Request

NorthScope accepts requests in either JSON or XML formats. The Web Services API will respond to a request with a document in the same format as it was requested. For example, if you make a request with a JSON document you will receive a JSON response.

Independent of format, the HTTP POST body will contain the document outlining both which request is being called and any parameters being supplied for. All requests have a root element named NSRequest, which has two child elements: RequestName and RequestContent. The value of RequestName defines which action is being requested. The value of RequestContent will vary from request to request and will contain the request-specific parameters (if necessary). Some requests do not accept any parameters and in those cases RequestContent can either be omitted or left as an empty element.

All requests will return with a basic set of information and will include request-specific return information. Much like the request body, the response body will consist of a root element named NSResponse, which will always include two children elements: Timestamp and Success. Timestamp will indicate the time at which the NorthScope Web Services API responded to the request and Success will be a Boolean indicating whether the request itself succeed or not.

Obtaining a Token

Authentication to the NorthScope Data Service can be accomplished by one of two means: static or session-based tokens. By supporting these two methods, NorthScope can accommodate the authentication requirements for many integration partners.

Using a static token

To use a static token, you must have a user configured in NorthScope that contains the API Key (token). Go to System > Users & Security > Users and either add a new user or edit an existing user that will be used for the API. On the Properties tab of the user, set the ‘API Authentication Mode’ to “Static Token’ and click the Save icon in the toolbar. When the page refreshes a new ‘API Key’ property will be visible, click the ‘Generate API Key’ icon in the toolbar to generate the token id. Once this is set, pass this information along to the party you are integrating with so they can use this value when using the API.

Note: It is recommended that you add a unique user for this process rather than using an existing user as this process is session specific so more than one process cannot be using NorthScope at the same time.

Requesting a session token

The request to obtain a token is made using the GenerateSessionToken request. This is the only request in the NorthScope Web Services API that does not require authentication information in the HTTP headers. The purpose of this request it to accept authentication information to be used in subsequent API calls.

When calling the GenerateSessionToken process to create a new token for use in subsequent requests, these headers may be omitted (they will not be used if supplied).

The token created from the GenerateSessionToken process will be tied to both the specific user that generated it as well as the IP address of the machine that issued the request. One user can only be authenticated from one location at a time (including the website itself) which means if a user attempts to both authenticate via the NorthScope Web Services API and log in to NorthScope itself, the earlier authentication will be invalidated.

GenerateSessionToken: JSON Example

GenerateSessionToken: XML Example

If the request was valid, a response will be sent as follows:

GenerateSessionToken Response: JSON Example

GenerateSessionToken Response: XML Example

If an invalid authentication request is made, the following result will be generated:

Example: Validation failure in JSON

Example: Validation failure in XML

Authenticating a Request

Except the request GenerateSessionToken, all other requests issued against the NorthScope Web Services API require authentication information. This information is supplied as headers in the HTTP request. The two headers required to be supplied are:

• NSLogin: This will house the email address of the user being authenticated.

• NSAPISession: This will house the token returned from a previous GenerateSessionToken request.

When calling the GenerateSessionToken process to create a new token for use in subsequent requests, these headers may be omitted (they will not be used if supplied).

The token created from the GenerateSessionToken process will be tied to both the specific user that generated it as well as the IP address of the machine that issued the request. One user can only be authenticated from one location at a time (including the website itself) which means if a user attempts to both authenticate via the NorthScope Web Services API and log in to NorthScope itself, the earlier authentication will be invalidated.

In the event the incorrect information is supplied, either when generating a new session token or when using a previously fetched token, you will receive an error from the web service of the following structure:

Example: Validation failure in JSON

Example: Validation failure in XML

Using a Static or Session token to make subsequent requests

 Once you have generated an API Session Token or are assigned a static token, you can then supply it, along with the login email, in subsequent requests like so:

Testing the Web Service API via Postman

Postman is a free tool for developers and can be used to test web service requests. You can find it at: https://www.getpostman.com/.

With this tool, it’s easy to test web service requests. Follow these instructions to test your first command.

How to test your first command

Part 1. Obtain a token

Note: This is only necessary if you are using a user that is not setup to use a static token.

Referencing the two screenshots below, set the following information

0. Download and install Postman.

1. Set the URL of the web service request. This is usually the NorthScope URL + '/services/ActionCommand.svc/APIExecute'.

2. Set the request type to POST

3. Set the message format to Text

4. Enter the login request XML into the bottom left pane.

Open

5. Verify in the headers tab that no other other headers have been set, other than those shown in the screenshot below

6. Click the send button to issue the request. The pane in the bottom right should show <Success>true</Success> and have a valid session token you can use for step 2.

Part 2. Send a request for data

1. Modify the bottom left pane to use the ListCompanies request XML.

2. In the headers tab, add a header for NSLogin. Set this to equal the email address used in part 1

3. Add another header for NSAPISession. Set this to equal the token retrieved from part 1.

Click the send button to issue the ListCompanies request. If the system is working properly, you will see a response in the lower right pane with a list of companies from the instance of NorthScope.

Now you’re able to test any of the web service requests listed below.

Available Requests

The NorthScope Web Services API exposes the following requests to perform automated functionality within the NorthScope system.

ListCompanies

This request will provide a list of NorthScope companies your user has access to along with the numeric identifier, DataEntityCompanySK, which may be required by other API requests. This information is not likely to change so it usually would only need to be called once (to fetch and store known companies).

Accepted Information

This request accepts no parameters, the RequestContent node could be omitted entirely (or left empty).

Example Requests

Example Responses

ListSalesOrders

This request will generate a list of Sales Orders in a given NorthScope company that match the supplied filtering criteria. Except for the DataEntityCompanySK, all criteria are not required, and you could provide multiple of any other criteria. The Sales Orders returned must match any of the provided criteria of a type. For instance, if you supply criteria of multiple sites and multiple order date ranges, any sales order that both matches one of the provided sites and one of the provided ranges will be returned.

Accepted Information

Example Requests

Example Responses

ListInventoryLots

This request will generate a list of Inventory Lots in a given NorthScope company that match the supplied filtering criteria. Except for the DataEntityCompanySK, all criteria are not required, and you could provide multiple of any other criteria. The Lots returned must match any of the provided criteria of a type. For instance, if you supply criteria of multiple sites and multiple items, any Lot that both matches one of the provided sites and one of the provided items will be returned. Any empty element can be included to indicate filtering on a value being not set.

Accepted Information

Example Requests

Example Responses

AllocateSalesOrders

This request will accept a list of allocations to perform, verify they are valid and then allocate the inventory from a given LotSK to a given OrderItemSK. Both LotSK and OrderItemSK can be retrieved from the ListInventoryLots and ListSalesOrders requests, respectively.

Accepted Information

Example Requests

Example Response

This request has no specific response, instead you would receive a generic success or failure with a timestamp and error (assuming the request failed).

InsertInboundIntegration

This request provides a way to leverage NorthScope’s existing mechanism for 3rd party integrations. Using the InsertInboundIntegration web request, data can be inserted into a NorthScope instance’s inbound queue.

Everything in the <Data> </Data> section is what will be placed into the inbound queue. For more information on the inbound queue and what to send there, see IM Adjustment (XML) as an example. The code below sends a fake transaction ‘TransactionABC’ of type ‘IMTransferXYZ’. To send a different kind of transaction to the inbound queue, simply replace the XML inside the <Data> </Data> section.

Example Request

Example Response

ListUOMSchedules

This request will retrieve a list of UOM schedules.

Accepted Information

The WhereClause parameter enables only a selection of data to be sent back in the reply, based on filter criteria written with SQL syntax. Any of the UOM schedule properties can be referenced.

Example Request

Example Response

ListSites

This request will retrieve a list of sites.

Accepted Information

The WhereClause parameter enables only a selection of data to be sent back in the reply, based on filter criteria written with SQL syntax. Any of the site properties can be referenced.

Example Request

Note: JSON is not supported for this command.

Example Response

ListSalesOrders

This request will retrieve a list of sales orders and sales order details.

Accepted Information

The WhereClause parameter enables only a selection of data to be sent back in the reply, based on filter criteria written with SQL syntax. Any of the sales order (not detail) properties can be referenced.

Example Request

Note: JSON is not supported for this request.

Example Response

ListItems

This request will retrieve a list of items.

Accepted Information

The WhereClause parameter enables only a selection of data to be sent back in the reply, based on filter criteria written with SQL syntax. Any of the Item properties can be referenced.

Example Request

Note: JSON is not supported for this command.

Example Response

ListCustomerAddresses

This request will retrieve a list of customer addresses.

Accepted Information

The WhereClause parameter enables only a selection of data to be sent back in the reply, based on filter criteria written with SQL syntax. Any of the customer address properties can be referenced.

Example Request

Note: JSON is not supported for this web request.

Example Response

Powershell Client Example

This document would not be complete without at least one example of how a client might access the web service. Below is an example client program that can obtain a token and request a list of companies from a NorthScope web service. Powershell may not be the best tool for your situation, but the client steps will remain the same, as implemented below.

To run this example, be sure to use the correct username and password, and the URL for your NorthScope server. Save as a ps1 file and run via the Windows Powershell application.