A CTO's Take on Building Product Integrations: An Interview with Prasanna Venkatesan

Kelly Sarabyn

Marketing and sales software require a number of product integrations to be useful to their customers.

Prasanna Venkatesan is the Founder and CTO of Insent, a conversational platform that helps businesses identify and engage their prospects. Early on its development, Insent integrated with all the major marketing platforms.

Prasanna shared Insent's approach to integrations, and his detailed advice for other startups on what to consider when planning out product integrations.

What is your current approach to product integrations?

Our product is a conversational layer that can be used for a number of different things, but right now, we are focusing on the marketing use case. We have built integrations into the major marketing platforms, like Salesforce, Hubspot, Marketo, and Microsoft. We have a team dedicated solely to building integrations.

Did you build the integrations yourselves?

When we started, I looked around for help, and to try to see if there is an easier way to build. I know Zapier exists and there are a few similar tools. But Zapier is designed for lightweight jobs. If you want to push some limited amount of data from one system to another, it can work. But if you are dealing in volume, it is too expensive.

Our use cases are too heavy for a tool like Zapier. One of our key features, for example, is that we provide our customers with the ability to create very detailed audiences on our platform, based on their data from their other platforms. As a result, we need to keep in sync with those platforms, and have API calls back and forth every few hours.

Integrations are core to our product and we decided to build them ourselves.

When did you build your external API?

We started with an external API. Our product does not really exist without an external API. A key part of our product is to identify visitors on our customers’ websites, and we use a bunch of integrations to figure out who the person is and how you should message them. Our customers have a wealth of data in their sales and marketing platforms that we need to track visitors and analyze how they should be addressed.

To build that layer, we needed an external API.

Do you have advice for startups looking to build an external API and product integrations?

First, I would advise not to start building integrations until you are very clear about the use case. Every platform has their own API and system that takes time to learn. Salesforce, for example, has a concept where they give you an access token, and it can expire at any time, and you just have to refresh the token whenever it expires. Marketo gives you an access token and it says it will expire in one hour. Slack gives you one that doesn’t ever expire.

‍

APIs are all different and you have to take the time to figure each one out. So you should always be sure what the use case is before investing all that time.

‍

Second, most of these platforms have good resources and support systems. Marketo has weekly dev office hours. For us, we got in touch with Marketo very late in the process. We tried to figure it out on our own, and we would have saved a lot of time if we had reached out for guidance in the beginning. I would recommend someone starting out look at the Marketo API and then run your plans by the Marketo team before you actually build.

Hubspot has a very good Slack community for developers, and that’s very helpful.

Each one of these large platforms has good support, and you should avail yourself. If you’re coding deep integrations, you will need help.

Another thing to realize is that often these companies have APIs that are so extensive that you can accomplish the same objective in three different ways. For example, with Marketo, contacts can be synced three different ways, and the Marketo team flagged for us that if we do it through the bulk option, we can dramatically reduce the number of calls we are making.

Third, when building integrations, keep the limiting factors in mind. Platforms limit how much data you can download at once, and how many calls you can make.

Look at these limiting factors, and factor them in your planning phase. You never want to cause your customer to not be able to make calls when they need to.

Given their complexity, planning your integrations is at least as important as building them.

Is there any technical advice you have for a company who is building their external API?

If you are going to be working with a lot of systems that are similar, you should plan your codebase around that. For example, if you are working with a lot of customer support systems, they have different concepts but many similarities.

You should avoid making your codebase system-specific. If Zendesk is the first integration you build, do not make your codebase Zendesk-specific. Build with objects that will make further integrations much easier.

When we first built we had a different codebase for each system, but we are now seeing there are a lot of commonalities amongst systems, and code that can be used across systems. If we had done that in the early days, it would have been easier for us now.

In terms of authentication, it is different with each platform. There are two main components to authentication - first, how do you get access to a token?

Salesforce and Hubspot, for example, both use OAuth, a very common approach that allows customers to come to the platform and say they want to connect, and then get access. With Marketo, on the other hand, you have to go in and click a bunch of buttons, get an API key and secret, which you have to then share in your application.

The second key part of authentication is does the access token expire and if so, what is the process to get a new token? In Salesforce, for example, the token expires but you have no idea when, so you have to build that logic into your codebase. Every function call has to include it. Marketo, on the other hand, typically tells you when the token will expire.

I’d also advise startups to gather information on the demands of different APIs at the start of the process. In my opinion, Microsoft has the most complicated APIs out there with very poor documentation, for example. You have to be super extra careful when you build with Microsoft APIs and plan for backups wherever possible.

Slack, on the other hand, in my experience, has the best set of APIs. They are very well documented, and they have a dedicated portal for developers where you can test your APIs.

You're a relatively early stage company. What is your focus right now for integrations?

Our current integrations are all native, the customer can access them from inside our app. We have established default configurations for each integration based on common needs, and the customer can change the configurations if they want to.

‍

Part of our roadmap is to offer an external API for third parties to build with but not yet. We are still focused on building integrations to larger systems. This has to be a business decision, and we look to what our customers are using. Our customers are medium to large companies, and they are all using these large systems.

‍

Moving forward, we will roll out integrations to more systems, as well as build deeper integrations into Microsoft and Slack.

In your experience, how much time and resources does it take to build a product integration?

It is a significant investment to plan and build your integration. These systems provide more than one way to accomplish the same thing, and you need to devote the resources to make sure you are building correctly.

‍

For very good engineers, with lots of experience working on APIs, it takes 2-3 months to build a deep integration.

‍

For very simple stuff, you might be able to do it in a week. But for a deep integration, I would advise 3 weeks of planning before you start the building phase.

You also have to consider other costs. Most systems do not charge you to get access, but Marketo, for example, charges 10k USD just to get access to a developer instance. Salesforce has a 2k security review.

The question you have to ask yourself is, “How am I going to get this money back?” If they have a marketplace for apps, for example, can you use that to further push your business? Are you going to have to expend additional marketing resources to drive leads through the marketplaces?

We have not listed our integrations on these marketplace yet. All our customers are using at least one integration, but our sales team has enough leads right now. It is on our roadmap to list in the marketplaces.

How do you track integration usage and errors?

We have certain tools built in, every time we call an external API for our customer, we track those numbers internally. I can pull up the numbers. I would definitely advise startups to build tracking into their integration infrastructure.

‍

Integrations are running in the background so it is easy to miss what is happening with integrations. Build tracking and alerting into your system. That is a must have.

‍

For example, if something fails more than 5 times, it is a red flag. It could be a mistake with the customer, but if you have a tracking and alerting system, you can go see what happened. We have the tracking integrated with our analytics tools so our business users, like a sales or CS person, can understand what is happening. You can use external systems like Kissmetrics to visualize alerts.

Currently, we do not alert the customer, we alert ourselves and fix any problems. Giving a dashboard to the customer is on our roadmap. Customers should be able to see integration usage and errors as well.

Anything else you’d like to add?

I am open to talk to any startups who are looking for help or advice on building integrations.

‍

No items found.

Posts you might like