Third-party integration: how it works and why it's tricky

Because third-party applications – like Twitter and Coveritlive – are an important part of the service that we offer, it felt like it was time to try to explain our thinking on how we work with them, both how that works but also why it’s not always the easiest thing to do.

Our applications are built on an in-house application platform which we call “Sunshine”. Sunshine provides the functionality,  user experience and interfaces that are common across our applications. This ensures that we have a common ‘look and feel’ for our applications – setting the Public-i style. It also means that, when we embark on a new product, we have a pre-built and tested base for our new application to grow upon.

Sunshine is sometimes dubbed a ‘social CMS’, but it is more appropriate to call it a ‘network CMS’, or an ‘integration/curation platform’, as one of Sunshine’s most important features is how it brings together networks of people (and information) into one place.

The nature of integrating third-party technologies is that we are beholden upon their suppliers not to make changes that create incompatibilities with previous versions. In some cases, data we integrate is delivered through a standard – RSS, for instance – but, for the most part, we integrate external data via interfaces (APIs, or Application Programming Interfaces) that the third-party makes available.

Integration of third-party data presents us with 3 main challenges:

1. Suppliers change their APIs. Sometimes this is to provide availability to new features, sometimes it’s because the supplier decides to change their policy regarding the data. Regardless of the reason for change, if API requests stop working, or stop bringing back expected results, our users and clients suffer. A case in point here is the recent policy change that Twitter made with regards to how external agencies can use their search API.
2. Suppliers are free to choose the technologies that they develop their applications on. This is a problem when these technologies are not aligned to our own. We are very conscientious of the fact that the audience for our products is wide ranging and has a very varied selection of devices, of all ages; our code is built around adapting to this variation in order to support as many potential viewers as possible. However, third-party suppliers typically have their own, narrower target audience and do not necessarily create applications or plug-ins that match our demands. Wherever possible we choose the supplier whose technology best matches both our functional and technological requirements but this is not always possible and there have to be compromises, which sometimes lead to a lower quality user experience than we would ideally like.
3. Not all suppliers are focussed on customer service. If there is an issue discovered in the integration of a third-party application into Sunshine, we can’t always rely on a timely resolution; in such cases we either have to: (a) find code a work-around – which adds to the maintenance cost of the integration; or (b) live with the problem – which, again, provides a lower quality user experience.

The nature of the technology we use and the utility of the products we create are such that there will always be new 3^rd-party applications with which we want to integrate. Our Product Managers are constantly on the look-out for new apps, technical advances and trends – judging their suitability for inclusion into Sunshine. It is in building a business case for such new integrations that we need to be very clear about the nature of the ongoing support of integration – only then can we decide whether it will be useful for our clients and their viewers, and cost-effective for Public-i.