A new API is big news. In between the lines of code, you can see the outlines of our future application. You'll also see that we made some remarkable choices while building it. Here’s a quick recap of the process.
Our previous API could use a little update - no news there. It dated back from when we first started, which is now a little over five years ago. Of course, we've added and replaced a thing or two over the years. But fundamental changes? Nope. Yet the world of software has evolved greatly over the years. That also applies to Teamleader as a whole. When building our previous API, we had about a hundred customers - now, we cater to more than 7000, spread across Europe.
"We'd like to thank all those involved for their contribution. The feedback we received from you played a vital part in designing our new API. We feel it's important to go through that process together, and build an end product with our partners, for our partners."
From product to platform
A new version was imperative - that much was clear. But you know how it goes: in the first place, your focus goes out to customers and your product. The API is used by developers, so it doesn't seem to be directly connected to user experience. That's why updating our API wasn't the first item on our to-do list. After launching our Marketplace, however, it made sense to take our next step to move from product to platform. A new API ensures that not only we, but also other parties can help expand the Teamleader ecosystem. This, too, is customer-centric thinking.
Last May, a couple of developers started designing our new API. Read: investigating the structure, features, conventions and principles. We spent quite some time on that aspect, so we could carefully apply the lessons we learned in the past. Our new API not only had to offer space to existing features - but also any conceivable features of our application in the future. That's why feedback was so important - and our developers sat together with other teams who could offer a fresh perspective to the matter.
We started writing the code in October, and about 70% of our development team was part of that process. Our developers applied the 'Documentation First' principle. In this principle, all specifications and properties of the API are clearly defined, so others can easily use the API later on.
This approach has a number of important advantages. For instance, it's much easier to implement a structural change made in one component in all other components. External developers can use that documentation to start developing and provide feedback. The team behind our mobile app is also using this same technique.
This method also allowed us to eliminate a couple of inconsistencies in our new API. Before, meetings, calls and tasks had different properties. We improved this in the new API - now, they're just displayed differently.
Change means making choices
After the documentation round, we collected specific feedback and suggestions - both internally and from partners. Change also meant making choices, of course - we decided to use RPC instead of the so-called REST-method, for example. You'll read more about that in this blog article.
We also changed course in terms of security, more specifically when it comes to authentication. From now on, integrations can access our application through OAuth2. This means end users no longer need to worry about API keys and can connect integrations in just two clicks. In addition to all that, our new API offers multiple access rights. The MailChimp integration for instance can access the CRM component of our tool, but not invoicing. This allows users to have a better idea of which data can be used by which integration.
An easier way of working
Our new API reverses the roles when it comes to building integrations. Until recently, it was mostly our own developers that had the knowhow to build those integrations. We felt this was not a customer-centric approach, especially given the high number of integration requests. This also made it harder for external parties to build an integration of their own. our new API will turn all that around - and allow external developers to get to work in an instant.
This role reversal also applies to us: if our developers build an integration or app, they'll now use the same API as everyone else. This will help us build the Teamleader community. Because, let's be clear: our new API is not the end, it's the foundation that we'll build upon.
Your feedback is vital
We made the first steps towards a new API, but we'll continue to work on this over the coming months. And we're counting on you to help us with that. Any feedback on the first endpoints of our new API, ideas you'd like to share or ways for us to make the new API even more user-friendly? We'd love to hear all your thoughts on the current version, which you can find through this link.
Anything that still needs to change? Did we miss something? Could our new API cause a conflict with your integration? Send your ideas and suggestions to firstname.lastname@example.org, we'll take care of it!