In our article, What is a meeting management platform?, we start with this statement:
"Lucid Meetings is an online meeting management platform for designing, running, and continuously improving the business meetings that power your organization’s success."
When you declare that you're a platform, you better be able to back that up with some reasonable definition about what that means. In the above support article, we list quite a few properties of a Meeting Management Platform (read about them), including one line about how only a few "platforms" connect to your larger business ecosystem:
Only a few meeting management platforms include ... "Open APIs and extensive business system integrations"
This post is about that one line.
Creating an Open API
An Open API, or perhaps better put, a Public API, is the user interface for software developers seeking to integrate an API-oriented application into other business systems. A Public API (application programming interface) provides documented mechanisms for external software developers to safely observe, measure, and control the application (Lucid Meetings). It's a contract of sorts between the people who create software and the people who would extend that software in new and interesting ways. I love Public APIs.
In the modern age, most web software either provides or makes use of internal APIs for connecting the core software pieces to one another. Lucid Meetings certainly does. But having an internal API does nothing for your external developer community; we've long recognized that a Public API would be a great addition for our Lucid customers and partners. Last month we finally fixed that deficit.
See related documentation,
The Lucid Meetings REST API, for a programmer's description of the entire API.
Developing an open, public API for a web service such as Lucid Meetings can be a daunting task. While there is no shortage of best practices recommendations, there is also no single, prescribed approach for doing this work. In short, there are many ways to get this wrong, and no precise way to get it right. To focus our attention, we established a few guiding principles at the outset:
- Create a full featured API with read, write, and modify capability
- Adopt a pragmatic, RESTful approach that developers could embrace
- Use established patterns for resources (nouns) and actions (verbs)
- Use established patterns for authentication and authorization
- Fully, completely, lovingly document everything about the REST API
- Provide a large sample of relevant examples in our documentation
- Demonstrate the value of the API with a single, significant integration
It's fair to say we focused a lot of development attention on the correctness and completeness aspects of the API. Essentially, we focused on the first six points in our guiding principles list, researching relevant API theory as well as the current pragmatic thinking about REST API best practices.
And all that work paid off with a well organized, very usable API for technical developers to create new and interesting integrations with other applications.
What About Our Non-Technical Customers?
The last guiding principle, about demonstrating the value, is perhaps the most important. We can create APIs till the cows come home, but if we can't show how they add value then we're pretty much just talking about their potential, rather than their reality.
We needed a way to showcase the value of our newly minted API and we needed a way to directly enable the success for thousands of customers and their people.
Enter Zapier (rhymes with happier!)