Posts tagged API

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.

QR Code leading back to this site

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.


Here’s yet another bit of Labs which we’re just kicking off – this time a big one (as in people who love data will love it). We’ve called it Nucleus, as in the centre of something, because it’s a little scheme of ours which aims to draw all the information which drives the heart of the University into one set of APIs.

The first very early look at our aim is the Locations API, or at least part of it. This is a RESTful interface (for those of you who know your types of API) to our database backend which runs on the frankly amazing MongoDB. The result is a really, really fast and flexible search of rooms.

To start with it’s been loaded with a small subset of the Spaces Database maintained by Estates, but in future this database will contain just about everything there is to know about a room. How many seats it has, which direction the windows face, if it’s air conditioned, if it has beanbags, when was it last carpeted and more could all (potentially) become available.

We’ll be adding application authentication to the Nucleus APIs soon (don’t worry, we aim to be pretty flexible about handing out keys) but for now the GET method to take a look at our rooms is open access. We know some bits of it are a bit flaky (floors) and some are just missing altogether (features, which worked with our 6-room test set but which we haven’t filled out data for the extended one) but we hope to improve those as soon as possible. Take a look at the documentation and see what you can make it do.


Through the amazing power of Yahoo Pipes and the Get Satisfaction API, I’ve cobbled together this little widget to show “what we’re currently working on”. In effect this is any idea or problem which is marked as “in progress” on Get Satisfaction. This data is available as an RSS feed as well (or JSON if you prefer), which could possibly be integrated with Portal to show what’s currently going on around the University or run through a visualiser and displayed on a large screen somewhere, just to be a bit more proactive in telling everybody what various parts of the institution are getting up to.