N200 Visit is Europe's leading event registration, ticketing and data intelligence platform. It is a web based, enterprise-wide application which enables event organisers to interact with their visitors and exhibitors and them with each other. The system optimises the data capture process and stores all relevant data in the N200 Visit Database.
The N200 Application Programming Interface (API) specifies how external software components should interact with the N200 Visit system in order to exchange information.
The main goal of the API is to facilitate automated communication - initiated from 3rd party systems / software packages - with the N200 Visit Database, mainly focussed on creating, reading, updating and deleting visitor and partner information.
The API can be used for many reasons such as;
The API is a link between the N200 Visit system and third party applications. You decide what you want to know or update. You give the commands to the API and N200 sends an answer back to your application with the most up to date information. All communication is processed via http get, post, put and delete messages.
The content of these messages is in XML format and according the conventions N200 has put forward.
The software you choose to create these XML messages and to communicate these to the API is a decision you make internally, normally based on your existing platforms, tools, architecture and skill sets. It makes no difference to N200 as long as the XML is formatted properly and communicated as described later in this document.
The API is a so-called RESTful API (Representational State Transfer). REST-style architectures conventionally consist of clients (you) and servers (N200). Clients initiate requests to servers; servers process requests and return appropriate responses. Requests and responses are built around the transfer of representations of resources. A resource can essentially be any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a resource.
The client begins sending requests when it is ready to make the transition to a new state. While one or more requests are outstanding, the client is considered to be in transition . The representation of each application state contains links that may be used the next time the client chooses to initiate a new state-transition.
Once the API has been enabled for a customer's account in N200 Visit, a so-called notification URL can be configured for the customer's account. A get request is made to the URL when a change occurs to a record.
This notification URL will be called (a GET request) notifications service whenever visitors are modified.
For example, if the web service notification URL configured is: https://getnotification-from-visit.com, and a visitor's registrant state is changed from registered to visited, a GET requested is made to the URL https://getnotification-from-visit.com?event=eventCode&visitor=visitorCode.
Important: The notification will only be sent when the visitor's status is 'registered' or 'visited'.
By using revision the API can return only those records that are new to you, or have been changed since the last time you requested them. The API has a built in Change control methodology - based on a revision number - to support his. All main resources can be requested via API using the revision methodology.
It is important that the client stores the latest revision number for each of the resources.
All individual records (not only contacts, visitors or partners, but also the other resources) have a change control methodology based on a revision number. Upon every change of a record in the Visit database the revision number will be heightened. This revision is also available throughout the various XML messages within the API, and can be used in consecutive API calls as a parameter to narrow down the results.
All lists will be multiple records, max 100, if more than 100; the more link can be used to get the additional records.
To be able to use API with N200 Visit, the Web Services contract module should be enabled for the organisation you want to access the data for. Once this module is activated, you will receive a so-called API Key, which you need to gain access to the organisation's data. If you want to use the implementation based on notifications, you can enter what is called the Notification URL on the Organisation profile page.
N200 Visit stores it's data in a central data model. This means that the information is divided in organisational- and event information. This is applicable to the various resources, as well as to the actual visitor information.
Therefore a visitor record is always split into two parts:
A contact can be linked to visitor(s) or partner(s) but not both!
For each type of information, also known as a 'resource', various details are available.