DEV Community

Code[ish]

21. Building APIs that Integrators Want To Use

Matte Noble is a Senior Software Engineer at Sentry, an application with the capability to stitch together different developer tools through their APIs. For example, an exception that occurs in your application can be automatically represented as an item in your project management tool's backlog. On top of this, Sentry provides a platform for tools to also integrate with. Matte identifies his past work experiences as leading him to conclude that when building an application like this, it's important to consider your two types of users as having distinct concerns: one group is content with using the product as-is, and another group is the set of developers who are building tooling and integrations for that first group. By intentionally building your product as a set of APIs that communicate with various systems, you simultaneously build features your users want that your integrators can build on top of.

In order to design a good interface, Matte says that it's important to keep the responses concise, in order to avoid blurring the lines between individual resources and their responsibilities. In order to translate your internal understanding of your product's primitives into something consumable, it's important to listen to your customers and ask what their needs are, before simply exposing an API that is hard to change once it's public.

Sentry's primary technical challenges are surfaced in one of two ways. First, there's an issue of consistency, in that if two services are being connected, and one of them fails for some reason, Sentry is responsible for reacting to that, even if the external service did not provide any indication that something went wrong. Second, while Sentry is sufficient at handling large volumes of data, the same might not be true of a service they are pushing data to. In order to make Sentry scalable, it's not just a matter of working with their own engineering and product teams: they must also be mindful of third-parties over which they have no control.

The episode concludes with Matte's advice for any organizations interested in offering an add-on marketplace. For him, it's about providing capabilities that make the integrator want to integrate with your platform. For example, if billing is a component of the marketplace, it's important to build tools and features that allow an integrator to understand the revenue that they're making from your ecosystem. It's also important to focus on request/response times and errors rates, so that you can have the confidence in the health of those integrations and fix potential issues as soon as possible.

Episode source