Web Service API
- Schuyler Horky (Unlicensed)
- Dan Weber
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:
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.
Parameter Name | Required | Value |
RequestName | Yes | GenerateSessionToken |
LoginEmail | Yes | The email address of the NorthScope User for whom the token is being generated. |
Password | Yes | The password to authenticate that user. |
GenerateSessionToken: JSON Example
POST /services/ActionCommand.svc/APIExecute HTTP/1.1
Host: NorthScope.example.com
{
"NSRequest": {
"RequestName": "GenerateSessionToken",
"RequestContent": {
"LoginEmail": "TestAPIUser@NorthScope.example.com",
"Password": "StrongPassword"
}
}
}GenerateSessionToken: XML Example
POST /services/ActionCommand.svc/APIExecute HTTP/1.1
Host: NorthScope.example.com
<NSRequest>
<RequestName>GenerateSessionToken</RequestName>
<RequestContent>
<LoginEmail>TestAPIUser@NorthScope.example.com</LoginEmail>
<Password>StrongPassword</Password>
</RequestContent>
</NSRequest>
If the request was valid, a response will be sent as follows:
GenerateSessionToken Response: JSON Example
{
"NSResponse": {
"Timestamp": "2018-09-20T15:21:23.425",
"Success": "true",
"ResponseContent": {
"SessionToken": "00000000-0000-0000-0000-000000000000"
}
}
}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.
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
Parameter Name | Required | Comment |
DataEntityCompanySK | Yes | The identifier for the company from which to pull Sales Orders. |
Status | No | The desired status for returned Sales Orders. Available values are: New, Released, In Process, Staging, Loading, Shipped, Approved, Ready To Post, Posted, or Void. |
OrderDateFrom | No | The lower bound for an acceptable date range for Sales Orders’ Order Date, inclusive. |
OrderDateTo | No | The upper bound for an acceptable date range for Sales Orders’ Order Date, inclusive. |
ScheduledShipDateFrom | No | The lower bound for an acceptable date range for Sales Orders’ Scheduled Ship Date, inclusive. |
ScheduledShipDateTo | No | The upper bound for an acceptable date range for Sales Orders’ Scheduled Ship Date, inclusive. |
LineItemSite | No | The desired Site for any Sales Orders’ Line Items. If this is provided the returned Line Items may not reflect all items on a returned Sales Order, if it has items that span Sites. |
LineItemCarrier | No | The desired Carrier for any Sales Orders’ Line Items. If this is provided the returned Line Items may not reflect all items on a returned Sales Order, if it has items that span Carriers. |
LoadID | No | The desired LoadID’s for any Sales Orders’ Line Items. If this is provided the returned Line Items may not reflect all items on a returned Sales Order, if it has items that span Loads. |
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
Parameter Name | Required | Comment |
DataEntityCompanySK | Yes | The identifier for the company from which to pull Inventory Lots. |
Item | No | The desired ItemID for the Inventory Lot. |
Site | No | The site in which the Inventory Lot resides. |
ProductionLot | No | The Production Lot ID for the desired Inventory Lot. Can supply an empty value to indicate filtering for lots where this is not defined. |
WarehouseLot | No | The Warehouse Lot ID for the desired Inventory Lot. Can supply an empty value to indicate filtering for lots where this is not defined. |
Owner | No | The Owner Name of the desired Lot. |
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
Parameter Name | Required | Comment |
OrderItemSK | Yes | The identifier for the Sales Order Line Item being allocated. |
LotSK | Yes | The identifier for the Inventory Lot from which the inventory will be drawn. |
AllocateUnits | No | The number of Units (in the supplied Unit of Measure) to allocate. Not required if the item is managed by Weight only. |
UnitsUOM | No | The Unit of Measure ID for the units in which the inventory is being allocated. |
AllocateWeight | No | The amount of Weight (in the supplied Unit of Measure) to allocate. Not required if the item is managed by Units only. |
WeightUOM | No | The Unit of Measure ID for the weight in which the inventory is being allocated. |
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
Parameter Name | Required | Comment |
DataEntityCompanySK | Yes | The identifier for the company from which to pull sites. |
WhereClause | No | Filtering parameter for returned data. |
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
Parameter Name | Required | Comment |
DataEntityCompanySK | Yes | The identifier for the company from which to pull sites. |
WhereClause | No | Filtering parameter for returned data. |
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
Parameter Name | Required | Comment |
DataEntityCompanySK | Yes | The identifier for the company from which to pull sites. |
WhereClause | No | Filtering parameter for returned data. |
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
Parameter Name | Required | Comment |
DataEntityCompanySK | Yes | The identifier for the company from which to pull sites. |
WhereClause | No | Filtering parameter for returned data. |
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
Parameter Name | Required | Comment |
DataEntityCompanySK | Yes | The identifier for the company from which to pull sites. |
WhereClause | No | Filtering parameter for returned data. |
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.