Cry Havoc and Let Loose the APIs of War

Those of you keeping up will know that my time at the moment is being mostly sliced up between Total ReCal, Nucleus, Jerome and Zendesk. Between them these four projects represent a monumental change in the way that a lot of things are done – that change is their reliance on APIs to achieve just about anything useful.

Today I’m going to focus on Zendesk’s integration with a few things, starting with hookups to a couple of new services we’re building to handle asset management and room information.

Very simply, each asset which currently has a barcode on it will instead gain a QR Code containing a URL unique to the asset. This URL leads directly to a web based asset management system which a) gives us a way of updating assets stupidly quickly, and b) lets people report problems in three steps: scan the code, describe the problem, click ‘report’. The issue will be slotted straight into Zendesk over the API, with user details seamlessly completed from our Single Sign On service, and the asset number already completed.

On the other side, whenever someone opens a ticket on Zendesk with an asset number associated with it a cool bit of custom code will leap in and grab the asset details from our database so we can instantly see not only the details of the problem but also everything we know about the asset in question.

Rooms will similarly be gaining a QR Code which leads to the room’s entry on Nucleus Locations, from where people can view the room’s timetable, book a slot and tap a single button to tell us about anything which has gone wrong. A totally seamless experience for the end user, but which backs off to our full-blown helpdesk solution so we can track, manage and solve issues.

Aside from the sheer awesomeness of being able to slot problems directly into the helpdesk using distinct applications (There’s also one in the pipeline as part of Jerome to help Library staff report and monitor problems) we can also use two bits of Zendesk goodness to make signing people in and populating the users database really easy.

The first of these is Zendesk’s SSO route, meaning that we can sign users in using their University credentials by handling the authentication part on our own servers and then passing Zendesk a ‘token’ which it swaps for user details. This makes sure that for every person who signs in to Zendesk we can pass over their email address, phone number and a few other details to help us identify them when they need support. Unfortunately this means that we will only have information available for users who have already logged in. However, through application of technology we can solve this.

Nucleus People, our front-end API to access details on everybody in the University, is currently being primed to continuously scan the directory looking for changes. Once it spots a change it will be able to notify various services, one of which is a script we’ve cobbled together to add and update users in the Zendesk user list over their API. This mysterious script will then perform a few checks and will perform the necessary changes completely transparently to the end users and agents, who will instead enjoy up-to-date (well, within a few minutes) information on every staff member and student in the University.

Alongside this will be a little bit of magic which assigns every user to an ‘organisation’ based on their faculty or department, meaning we can get a better idea of who experiences which problems. Finally, a ‘tidying’ script will clean up a user (but not their tickets or history) once they disappear from the directory, for example when they leave the University.

The underlying processes which support this voodoo are still being fine-tuned due to their sheer complexity in validating data and making sure we don’t suddenly start calling everybody the same name, but suffice to say they would be a damn sight harder if there weren’t APIs available at both ends of the data transfer process.