Heidi Williams co-founded tEQuitable, was the VP of Platform Engineering at Box, and managed strategic partnerships at Adobe. She shared her insights on building product integrations, the importance of in-app marketplaces, and best practices around APIs and the technical infrastructure that enables tech partnerships to be successful.

What was your experience working with APIs and integrations?

I was at Box for 4 years as VP of Platform Engineering. When I started, my team was working on our APIs, SDKs, embeddable widgets, and partner integrations.

We built our own integrations or did so in collaboration with partner companies like Netsuite, Salesforce, and Jive. But we also had APIs and SDKs that anyone could build with, whether to integrate with another SaaS app, integrate with internal systems, or to use Box capabilities to power new apps.

Did you have any restrictions on accessing your API and SDKs?

Everyone had to sign up for a Box developer account. Once you did, that would give you a Box instance. By signing up for an account, your app could access content in your own instance, but you would need permissions to access anyone else’s. This provided a high degree of security for our customers as they had to grant access to any third party apps and developers.

There was a process for publishing an app so that it would be available for Box customers to use. We looked into adding a more rigorous security certification of third party apps so we could highlight those apps to more users, but that required a great deal of resources.  

What would be your advice to SaaS companies just starting on the process of building product integrations?

I would advise them to think about the security model. At Box, we kept increasing our security posture in the API to make sure that we were not putting customers at risk.

In general, app developers building integrations fall into 3 categories. The first is larger customers who are building integrations for their own internal use. Imagine at a large company, they might have a number of developers building integrations to your product for their internal use.

The second is what I would call a third-party developer. This is someone you have never heard of, and have no relationship with, but they just built a cool integration with your API.

The third category is partner developers, where you have a relationship with them and their company.

There is a different level of trust for these tiers, and it is worth thinking through what capabilities and permissions you want to extend to each one. The most trust is, of course, when you are partners and building something together. But companies should think through the use cases, and decide what extra security measures or further hoops different categories of developers should go through to keep your customers’ data safe.

What should companies think about when they are building their API?

I always think about the risks with an API. An API is called by other software. For that reason, the scale that you can get to with an API is higher than when you just have human customers using your application. A human can’t perform a million actions in one minute, but software calling an API sure could!

So it is important to think through how you ensure that someone does not crash your site because someone has an infinite loop running or is maliciously trying to overload your system. It can certainly happen by accident, so you need to protect yourself from these kinds of cases.

You have to set rate limits, and implement security that prevents the system from being crashed. You have to assume the end developer is doing the worst, and then figure out how you control for that. And be prepared so the site won’t go down.

‍

Another important practice is to expose the absolute minimum amount of capabilities through your API that you need to. It is hard to evolve the API over time, and if you need to make a breaking change, it takes a long time to get all the external developers to update their code. If you expose the least amount of features in the API in the beginning, you can always make additions over time, and to avoid breaking changes.

‍

In order to keep it minimal and the footprint as small as possible, a company should think through what they truly need to expose. For example, maybe you can have APIs expose some objects that are common for integration use cases, but not expose others. Or maybe internally there are 20 fields for an object, and your API only needs to expose 5.

How would you recommend figuring out which of these capabilities are essential?

Customer research is the most important component, and you should conduct this with your partners. At Box, we would do customer research with our partners, and we would ask joint customers, “What capabilities would be useful to you?” This would give us granular insight into what was actually needed.

Is there a way to ensure the developers who are building the APIs and integrations get the correct information about what customers need?  

In my experience, a partnership manager isn’t often super technical. So I am always a believer in engineers participating in these customer research projects. At Box, the partner manager would set up the meeting, and then engineering and product management would go along to the meeting. This way, the engineers would be clear about what they are building.

What else should companies consider when they build their first set of public APIs?

Many companies are likely adding APIs to an existing codebase that doesn’t already use APIs to power their own web application UI. If that is the case, there is a danger that third parties using the API may get slightly different behavior than a user using your web application. This is because there are two different code paths (the web application UI and the API) which means there are opportunities for bugs to creep in and behaviors to diverge.

If possible, look into rewriting your web application UI to use the same APIs you offer to third parties. This will require that all engineers think about quality, consistency, backwards compatibility, and how to avoid disrupting developers who use the API as a first priority instead of an afterthought, because of the impact those things could have on their own web application.

Are there any other best practices you would recommend for building an API?

It has become standard to build a REST API with a JSON response.

The authentication world has evolved, and has shifted to using OAuth and JSON web tokens. I would recommend going to Auth0, a company that provides authentication as a service, for great content on these changes and why they are important. Generally, these changes have improved security and given more granularity and control.

Are there technical considerations that are important to think about in anticipation of having an in-app marketplace?

At Box, our own success shot us in the foot. There were thousands of apps that connected with Box, and we had never put in place a way to sort out which ones were good, and which ones were being used. And the admins for our customers had no easy way to discover apps they wanted employees to use or block apps they didn’t want employees to use. It was a big project to rebuild the marketplace with new capabilities for governance and discovery.

‍

So you should think ahead about what happens when there are thousands of apps available, and how you categorize and vet them. That requires building a marketplace with those capabilities from the beginning.  

‍

In addition, you should think about co-marketing and payments. When you establish a partner program, you will want to do co-marketing, for example, and you have to think through the technical infrastructure for highlighting an integration or app within your app.

What were the challenges to building the in-app marketplace?

Building your own in-app marketplace from scratch will always compete with the priorities of building features that differentiate your app. While having an ecosystem is a differentiator, building out the specific features of an in-app marketplace is not a differentiator. So looking at options like Pandium makes a lot of sense, so your engineers can focus on product features that give you a competitive edge.

How important do you think it is for SaaS companies to build connections to other companies?

I think there is a huge value in building out a tech ecosystem. If you can find ways to do it, there is marketing value, you can tap into each other’s customer bases, and you can expand your footprint.

The ecosystem can be a moat for your company. Customers can’t take you out of their tech stack if you are intertwined with 40 other companies they are using. When you are inside an ecosystem, you become integrated into everyone’s daily life and how they use their software.