Our Open APIs (REST Web Hooks) allow you to integrate NoahFace with your existing IT systems and applications. For example, you could:
The opportunities are endless.
NoahFace can automatically retrieve your list of users from an existing IT system so you don't need to import/export users or manually maintain them in two places. To do this, you simply implement our User Synchronisation API (a REST Web Hook), and configure NoahFace to call it.
Your implementation of the User Synchronisation API should return JSON data. The JSON data should contain a single element called Users, which is an array of all of your users. Each user can contain any of the following elements:
Only the SyncGuid and at least one of the Name and FirstName elements are mandatory for each user. However, the more attributes you return the more functionality you will have available to you within NoahFace.
The following is an example of the JSON that your API should return.
To enable user synchronisation, simply add a synchronisation instance, select 'Custom' as the type of synchronisation, and specifying your API endpoint details (see example below).
NoahFace can synchronously update an individual user while they are recording an event (eg: while they are attempting to clock in for work). This is used, for example, to ensure that a user's expiry date is up to date before denying them access based on their currently recorded expiry date.
To support individual user synchronisation, your user list url should accept an optional query parameter of syncguid, and when this query parameter is present, it should only return the user with that guid.
Supporting individual user synchronisation is entirely optional; if you don't need this feature, you do not need to support this query parameter.
Your API should return an HTTP response code of 200 on success, and an appropriate response code on failure (eg: 404 if the specified User list url is incorrect, 401 if access was unauthorised, etc).
NoahFace can forward user events to your applications or IT systems. To do this, you simply implement our Event Notification API (a REST Web Hook), and configure NoahFace to call it when a user records an event.
Your implementation of the Event Notification API should expect to receive the following elements:
Your API can be designed to be called using an HTTP GET, PUT, or POST method. If you use GET, the event data will be sent in query parameters. If you specify PUT or POST, the event data will be sent in JSON format (see example below).
The following is an example of the JSON that your API should expect. All elements will be present even if they are empty.
Each event includes an event type attribute. The full list of possible event type values is as follows:
Different event types are generated by different screen types. For example, if your are using the Clock In/Out screen, the only event types you will receive are: register, clockin, clockout, and accessdenied, and if you are using the Task Tracking screen, the only event types you will receive are: register, starttask, clockout, and accessdenied. You can generally ignore register and accessdenied type events.
Each event contains an event detail attribute. This is populated with any data that is collected with the event. For example:
Processing the detail attribute can therefore help you automate cost allocation.
You can forward user events either from the Cloud or locally from the NoahFace App. Forwarding user events from the Cloud is usually used for integration with payroll systems.
To forward user events from the Cloud, simply add a notification, select 'Custom' as the type, and specifying your API endpoint details (see example below). Once you have done this, associate this notification with an access point type, and create your access point.
Your API should return an HTTP response code of 200 on success, and an appropriate response code on failure (eg: 404 if the specified url is incorrect, 403 if access was unauthorised, etc). If you return anything other than 200 (or your API cannot be reached), then NoahFace will attempt to re-send the event the following number of hours in the future:
2 ^ (number of failed attempts - 1)
So, the first retry will be after 1 hour, the second retry will be after an additional 2 hours, the third retry will be after an additional 4 hours, etc. This will continue until your API returns success, or until 90 days has passed.
You can forward user events either from the Cloud or locally from the NoahFace App. Forwarding user events locally from the NoahFace App is usually used for integration with local hardware (eg: unlocking a door or printing labels). You can also use local event forwarding to retrieve and display real time messages to users.
To forward user events locally from the NoahFace App, select your access point type, select 'Web Server' as the Receiver type, and specifying your API endpoint details (see example below). Once you have done this, create your access point.
Your API should return an HTTP response code of 200 on success, and an appropriate response code on failure (eg: 404 if the specified url is incorrect, 403 if access was unauthorised, etc). You can optionally return a custom HTTP response header of X-NOAHFACE-MESSAGE to display a message to the user. It is critical that your network connection is reliable and that your API returns quickly (ie: ideally in less than a second), as local event forwarding is synchronous.
Your implementation of the NoahFace APIs should enforce one of the following authentication methods:
If your implementation of the NoahFace APIs is being designed to service multiple organisations, you should use different credentials for each organisation so you can access the appropriate data in your IT system or application.
Regardless of which authentication method you choose, all API calls are over SSL so your data and credentials are encrypted.