Design for Simplicity and Flexibility, and Let Users Bring Your Products to the Next Level – InApps Technology 2022

We built Aircall with the idea of offering a simple, easy-to-use and powerful phone system. The beauty of this product is that it hides the complexity of the telco-world behind a super simple user interface (UX), so that anyone can recreate a call center in less than 10 minutes.

The Engineering team tried to apply this same idea to the whole technical stack. Aircall Public API exposes all the frontend features via a simple to understand REST API, following all development good practices that developers are used to.

Those solid technical and API design foundations built five years ago still power our Public API, now handling more than one million API requests and two million Webhook events per day.

Why Did We Build a Public API?

Back in 2015, we wanted to give our most tech-savvy customers the ability, with technical resources, to:

• customize their Aircall workflows
• retrieve their data and push them in their analytics tools
• Integrate Aircall with their customer relationship management (CRM) software.

So we’ve exposed the main objects via a simple and well-documented CRUD API and started sending Webhook notifications for some basic events happening.

Very quickly, we saw customers using our Public API in ways that we could have never imagined. They were building features on top of Aircall for their own usage, from real-time analytics dashboards to deep-integrations with their custom CRMs.

This Public API allowed to quickly build ten CRM and Helpdesk integrations. Each integration was built on top of our Public API and Webhook foundations and took us about two weeks to build. Having designed so well our Public API allowed us to quickly iterate on integrating Aircall to external business tools.

First Partners, Changing the Public API Morphology

In 2017, PieSync, Gorgias, and Kustomer released the first three partner-apps built on top of Aircall. They were getting Aircall phone features on their platform, to their customer base.

Funnily at that time, our Public API was designed for our customers, not at all for partners. Those first partners managed to find workarounds despite the fact that no guidelines were given.

It forced us to shape our Public API so it can fit multiple use-cases: we built the foundations of the Ecosystem of voice, building features asked by partners (like OAuth) on our Public API. Today, we offer partners a suite of tools, allowing them to be published on the Aircall App Marketplace. Each one of our customers can add as many software integrations they’d like to their Aircall account, adding features and connections provided by external tools.

Aircall’s App Marketplace now hosts more than 90 apps, 70% of those built by partners.

How the Public API Was Built

In 2015, we didn’t have the micro-architecture that is now running our services in production. Our backend was entirely built on a Ruby-on-Rails monolithic platform, rendering an internal API serving front-end applications.

We decided to build the Public API on the same foundations as our Internal API, which allowed us to iterate quickly on the scope and features of it. We only were using different serializers and homemade rate-limiting middleware.

Over time, we never needed to change the design of this API. We were able to add features on it and didn’t have to update or remove any field from it. But as the number of partners started growing, the number of requests made on the Public API was increasing considerably. The stack behind the Public API changed so much in a few years: we went from two EC2 servers behind a load balancer to an auto-scalable and replicable containerized ECS platform.

Our Vision for the Coming Years

Aircall had laid down its vision to build the first Ecosystem for voice with a solid Public API used by partners and customers. Our Architecture team is currently working to build the groundwork for the second version of our Public API. Our backend stack today runs many microservices, with several databases, written in different languages, and implemented with distinct architectural patterns. Our Engineering manages to bring this complexity back together via an event-based designed architecture, implemented in every microservices.

This new architecture will help us scale Aircall more efficiently, serving more and more Public API requests with the ultimate goal of giving simple tools to developers so they can build the Ecosystem of voice with us.

Feature image via Pixabay.