Advice for Startups Building Integrations: An Interview with Josh Holat, CTO of Cube

Cube is a software for finance teams that is designed to work from within Google Sheets and Microsoft Excel. As a result, its teams is well familiar with how to integrate with other systems. Cube's CTO Josh Holat shared his advice for startups who are looking to build integrations to other systems.

Can you tell me about Cube and your integration landscape?

Cube is aimed at CFOs and finance teams who do the majority of their work with spreadsheets. Our product is a Google Sheets and Microsoft Excel add-on alongside a separate web UI where the user sets up their company within Cube.

We have our own API that we built to power our add-ons. Our API is only used internally right now, but customers will be able to use it to build their own integrations.

We support many integrations for our customers where we pull in source data. These include products like QuickBooks and Salesforce. From software like QuickBooks we pull in transactional actuals data. From software like Salesforce we pull in driver/operational data which helps financial analysts predict future growth and outlook.

What API design did you choose?

We use REST design for now. It was the simplest to get up and running in the beginning so we could focus on solving our customer’s core problems. We may look at something like GraphQL in the future if it supports our needs, but the tried and true REST design has been working well for us so far.

How did you decide which integrations to build first?

The approach we’re taking is that when a large percentage of our customer base are using a system, we’ll build and support those integrations internally. This is to ensure those integrations are solid and reliable. For us, those are systems like QuickBooks, Salesforce and Xero.

There are various other systems, like Sage Intacct and Microsoft Dynamics, that we might build next depending on customer demand. One reason we built an API is that if we have a customer with an obscure system, they are able to build an integration themselves or hire a consultant to do it.

How was the process of building integrations?

A big part of the process is learning the nuances across the different APIs. We are generally pulling the same data from different systems, but depending on the system it can be quite easy to pull that data in a structure we need or rather difficult. This also applies to rate limits. Whereas bulk importing may work from one API, another may have strict enough limits that this becomes harder.

For some of the enterprise systems we integrate with another issue is access to sandbox accounts and data. Typically these aren’t offered at all which makes building and testing the integration more complicated. Simpler SaaS products like QuickBooks make this very easy by offering one click sandbox set ups.

‍

Supporting integrations long term also becomes a significant time investment. After you build a basic version of an integration, you still have to maintain it. As you onboard more customers, they’ll often be using different data from the source system which requires expanding the support for that integration.

‍

Also, APIs change and deprecate endpoints over time, so you also need to keep on top of those updates. Luckily, finance APIs are more careful about changing so this is not as big of an issue for us as it may be for people working in other industries.

In terms of process, adding in the first integration of a particular type of system is typically a longer process. You most likely need to make decisions around where that data is going to live in your database and what spots in the UI your user will be able to interact with that data. Then when you move from one system of a type to the second system of a type, you can then determine what pieces can be shared vs how your normalized storage of that data needs to be altered to be more flexible.

Related Content: 10 Integration Best Practices from a CTO

What is your technical advice for saving time on building integrations?

Normalize the data that makes sense in your system and then translate that to the other systems of that same type. The more you can share business logic across systems, the better.

We have created a normalized transactional data table, for example. We work off that code to integrate with all the systems where we are pulling transactional data. The goal is to find the most generic terms in those types of systems.

What are some important technical considerations when building integrations?

First, be extra attentive to security. The way in which secrets and tokens are stored and dealt with should be very secure. If people get into your system and then they find the tokens for access to your customer’s connected products, you have expanded the breach. Furthermore, anywhere you move or store your data needs to be as secure and compliant as you are.

My second piece of advice is to make sure that you have good demo accounts for the external systems. If you have someone at your organization who is familiar with that particular system, say an accountant or finance person who knows how to use Quickbooks, then you can populate that account with dummy data and then test the integration.

Related Content: SaaS Integrations 101: Advice and Best Practices From a Sr. Engineer

What’s your logging and alerting system for integrations?

We have general logs and monitoring around when third party systems return unexpected responses. Depending on the severity of the event, it gets logged to various places (Sentry, Slack, etc). We then handle it from there. Generally, the more logging the better. You just have to be careful that you aren’t logging unnecessary customer information.

Do you have advice for smaller companies looking to build into larger systems?

My general advice is every API has weird behavior or edge cases that aren’t documented. If you’re using an API for a rather large/complex integration, the chances of coming across these increase. Creating workarounds for these edge cases is typically what takes the most time when building the integration.

You also might run into issues only with certain customers because they have a use case or data within their usage of that system that other customers do not.

‍

Generally you are never done with integrations because you have to keep updating them for new customers or if the API changes. It becomes an ongoing project that takes a fair amount of resources over time.

‍

Larger companies tend not to be very responsive to support for their API. Typically as long as the API is working for the majority of their customers they aren’t very interested in resolving any issues. In these cases it’s often just to assume the API isn’t going to change or be updated, so you need to head down the path of building your own workaround. Then if the API does get adjusted later, you can simplify your code at that point in time.

Generally, API documentation has gotten better. Companies have realized that docs are important to get developers to build on top of their systems.

Related Content: Partnership Leaders Share Advice on Building Out a Technology Partner Program

Do you have a team specifically devoted to integrations?

I am a big believer in the bus factor. Generally knowledge should be shared amongst various individuals to avoid issues if any one person were to no longer be at the company. We typically might have one engineer who builds the initial integration but then other team members will understand how it works as well. This happens via code review or having other engineers built on top of the initial integration. Integrations are integral to what we do, so it would be hard to isolate that knowledge to a particular team.