Net2 Local Web API
Getting Started
Certificate Manager
Methods
Version History
Contact Us

Paxton Net2 API

The API has been developed to allow third parties to be able to integrate their product(s) with Paxton's Net2 access control software.

However in order to use the API a licence is required to be granted from Paxton Access.

Licensing

You can request a licence by contacting our support department with the following information:

  • Company Name
  • Contact Name
  • Contact Email Address
  • Contact Phone Number
  • Type of planned Integration (Visitor Management, Time & Attendance etc.)

If the request is via email then please include the following in the subject "Request for Net2 API licence"

Pending approval, you will then be sent a licence file from the integrations manager.

You must not rename the file or edit the contents as this will cause the licence to be invalidated.

This file will need to be placed in this location:

[INSTALL_LOCATION]\Access Control\ApiLicences

The default location on Windows 10 is "C:\Program Files (x86)\Paxton Access\Access Control\ApiLicences".

After placing the file in this location, you must restart the Net2 Service to enable the ClientID.

Note, the name of the file is your ClientID which is used for authentication as explained in the next section.


Authentication

The Net2 Local Web API is secured using JWT access tokens and refresh tokens following OAuth2 standards. Other than a very limited set of routes, you must first obtain an access token in order to make calls in the API.

Access tokens are valid for 30 minutes and refresh tokens are valid for 2 hours. This is to allow you to re-authenticate without having to provide user credentials every time but also to have to actively maintain authentication to allow for changes to be made to operator access with minimal delay.

Access Token Authentication

Access token authentication requires the following x-www-form-urlencoded parameters:

  • username - Formatted [First Name] [Last Name].
  • password - The operators password in plain text.
  • grant_type - Set as "password".
  • client_id - Taken from your licence file.
  • scope - If you require a refresh token, set this to "offline_access", else omit this parameter.

These parameters are provided in the body a POST to the /api/v1/authorization/tokens route. This will return the following:

{
  "access_token": "eyJhbGci...obLvVU8A",
  "token_type": "bearer",
  "expires_in": 1800,
  "refresh_token": "719560b5b5194eec819ae1e25f54ba41",
  "expiry_datetime": "2019-09-17T11:51:20.9832179Z"
}

The access_token must then be provided in every API call.

This is included in the "Authorization" header in this format:

bearer [access_token]

Replace "[access_token]" with the value returned from the API e.g. eyJhbGci...obLvVU8A

If this token is not provided or the token has expired, then the call will result in a 401 error.

Refresh Token Authentication

Refresh tokens allow you to maintain authentication without having to provide the user credentials every time.

Refresh token authentication requires the following x-www.form-urlencoded parameters:

  • refresh_token - The refresh token obtained when requesting an access token.
  • grant_type - Set as "refresh_token".
  • client_id - Taken from your licence file.
  • scope - If you require a new refresh token, set this to "offline_access".

These parameters are provided in the body a POST to the /api/authorization/tokens route. This will return the same response as the access token request but with a new access token. This new access token will need to be provided in place of the old one.


Versioning

Occasionally Paxton Access may make changes to the API in order to fix bugs, introduce new functionality or general improvements.

There will only be a change in version number when a breaking change is introduced to the API.

A breaking change is defined as:

  • A change to the method signature e.g. changing a parameter type from an integer to a float, adding a required parameter or removing a parameter.
  • A change to the response of an API call e.g. changing a type from an integer to a float or removing a property from the response object

Specifying the API version is performed by sending the version number in the URL e.g. api/v1.

If you specify an invalid version or an invalid URL then the API will return a 404 response.


Events (SignalR)

As we use Angular here at Paxton, this is what we know best. Therefore, we will explain how to get started with SignalR using Angular/Typescript. If you need help setting up Angular, please refer to the official documentation at angular.io.

The Net2 Local Web API uses SignalR 2 for ASP.NET to provide live event reporting. This library has a dependency on JQuery when used in Javascript/Typescript.

The first step is to install these dependencies. You can install the dependencies via NPM using the following command:

npm install jquery signalr

After installing the dependencies, the scripts need to be added to your angular.json file within the scripts parameter. The scripts should be located here:

"node_modules/jquery/dist/jquery.min.js"
"node_modules/signalr/jquery.signalR.min.js"

Now we have the dependencies installed, we can create the service to hold the SignalR logic. This can be done using the Angular CLI with this command:

ng generate service signalr

In the service just above @Injectable, add this line to gain access to the JQuery methods:

declare let $: any;

NOTE: We are not using the strongly typed JQuery character as this prevents the use of the SignalR methods. It is possible to install the JQuery and SignalR types but this is a personal preference and not necessary.

Next we need to create the SignalR Hub Connection and Proxy. The SignalR Hub name is eventHubLocal.

private _connection: any;
private _proxy: any;
this._connection = $.hubConnection('http://108.28.63.84:8080');
this._proxy = this._connection.createHubProxy('eventHubLocal');

To authenticate, you need to attach the access token to the query string for the connection:

this._connection.qs = {token: 'eyJhbGci...obLvVU8A'};

Once created, you can start hooking up the event listeners. There are three end points which can be listen to:

  • liveEvents - A live stream of all monitorable events in Net2. This does not include System Events.
  • rollCallEvents - A live stream of users being marked safe or unsafe in roll call.
  • doorEvents - A live stream of door open/closed status events.
  • doorStatusEvents - A live stream of door status updates.

You can hook up the listener like this:

this._proxy.on('[EVENT_NAME]', event => {
  // Do stuff here
}

Event Models:

  • liveEvent
  • rollCallEvent
  • doorEvent
  • doorStatusEvent
{
  eventTime: string,
  eventType: number,
  eventSubType: number,
  tokenType: TokenCategory, // (enum - Token = 0, PIN, VehicleReg, Code)
  tokenNumber: number,
  userId: number,
  userName: string,
  deviceId: number,
  areaName: string,
  details: string,
  notificationType: "EventsReportEvent"
}

By default, you will not receive any events from these. You must first prompt the server to push to these endpoints. You can do this by invoking the following methods:

  • subscribeToLiveEvents - subscribes to all live events generated by all ACUs.
  • subscribeToRollCallEvents - subscribes to the safe/unsafe events in a particular roll call. You must supply the roll call ID as a parameter.
  • subscribeToDoorEvents - subscribes to the open/close events of a particular door. You must supply the door address (serial number) as a parameter.
  • subscribeToDoorStatusEvents - subscribes to the status updates of a particular door. You must supply the door address (serial number) as a parameter.

You can also unsubscribe from these by prefixing "un" to the method.

You can invoke these methods like this:

this._proxy.invoke('[METHOD_NAME]', '[PARAM_AS_STRING]')