“The debate you’re having is a classic software debate — all in one, or piecemeal”

After two blessedly silent hours while my daughter played at a neighbor, I headed next door to pick her up. When I got there, the children were just starting to clean up the toys. While I waited for my daughter to finish helping, I settled on my neighbor’s couch, together with her sister, Rena, who was visiting.

Our small talk quickly shifted to work.

“I work as a personal assistant for the partner of a growing law firm,”  Rena shared. “What about you?”

“I set up and create software systems for businesses,” I answered.

Just then my daughter finally emerged from the playroom. As I started walking to the door, Rena followed me.

“Really? So, you deal with things like project management, CRMs, and that kind of stuff?” she asked.

I laughed — she made it sound so simple. “Yeah, something like that…”

“Listen,” she said, “I would love to speak with you about a question that has cropped up in the office lately.”

Rena and I swapped numbers, and that’s how I found myself sitting in their law firm, drinking coffee, a week later.

“So technically, we already have software set up,” Rena started off. “But we’re considering setting up a whole new system. I just wonder if it’s really necessary.”

“What’s wrong with the system you have now?” I asked.

“We have a bunch of different programs working as parts of a bigger whole,” she started. “So there’s a project management system for internal tasks and projects, a CRM for managing clients, and a system that does our billing. We end up entering and reentering the same data over and over. Some of the staff think we should find an all-in-one solution, but others, myself included, are reluctant. We’re so happy with the software that we have, and I was wondering if there was another way to go about all of this.”

I sipped my coffee — Nespresso. Nice.

“The debate you’re having is a classic software debate — all in one, or piecemeal,” I reassured her. “There are pros and cons, which we can discuss later, but first, let’s discuss your other option.”

Using APIs to Connect Software

Many companies find themselves needing to use a few different software systems to fill all of their needs. And although it might sound nice to use one software for everything, for many companies, using different systems and software makes more sense.

Take, for example, a company in which each team uses a different system, so no one person deals with two systems. In that case, there’s no need to switch to an all-in-one solution.

That being said, we’re still left with the issue that using multiple software often means entering and reentering the same information. The good news is SaaS platforms (“software as a service” online platforms) are able to “talk” to each other, solving the problem — if things are set up properly.

Software programs communicate with each other using something called an API (application programming interface). It’s basically an agreement between two pieces of software. Think of an API as a pipe between two softwares allowing the transfer of data. By using an API to connect two softwares, they now have a way of sending each other information.

Sometimes when you integrate two platforms, they may already have an API set up for you, and you can easily integrate them, like Microsoft Outlook to Zoom. Zapier can also be very helpful; it’s a connecting platform that has a wide variety of APIs set up for existing platforms. You can use it to connect platforms or make automations.

But what if you want to integrate two platforms that do not have a pre-set integration, or the pre-set integration does not allow you to do what you wanted? That’s when you can use APIs to set up your own integration.

How does that work? It’s actually really similar to when you sign into a platform or service. You have a user name, a password, and sometimes second-factor authentication to prove that you are privy to this information.

An API is basically the same thing. Except instead of a user wanting to access information, it’s another software that wants to access the information. Same concept, slightly different execution.

Each software has its own API code, and that code is different for every account in that software. An API code is unique to your account, just like your password is unique to your account. If you and your friend use the same software, you’ll each have a different API code. A software implementer can take the API code from software A and give it to software B. Now that software B has software A’s API code, software B can access information that is in software A.

Rena interrupts me. “One second, let’s say we take the API code from our CRM and give it to our billing system. So now our billing system will have access to the information from the CRM, correct?”

“Yes!” I smile, relieved that she understood.

“Okay, but now how will our billing system know what to do with that information? How will it solve the issue of needing to enter the information multiple times?”

“That’s the million-dollar question.” I tell her.

Setting up an API

Setting up an API is not as simple as just taking a code from one software and giving it to another; for Exhibit A, see Rena’s question. While the key component here is the API code, setting up an API includes many other things as well. Generally, only a software expert can set one up.*

The software expert who sets up the API will create a scenario that tells the software when to retrieve information from the connected software. The software will know when to retrieve the information, what to retrieve, and what to do with it.

For example, you can program an API so that whenever you enter a new client in your CRM, the billing system will know to retrieve the information about that new client and save it as a client in its own database.

Setting up an API might be a bit complex — but that’s for your software expert to deal with. Once it’s set up, it will do all of the data transferring for you, but you won’t even know it’s there. If you work with multiple software solutions, an API can minimize so much of your work.

“Wow.” Rena looked impressed. “I have to talk this over with my team, but I think you may have saved the day!”

“Happy to help,” I said.

“And it won’t change the way our software works at all?” Rena asked again, nervous that the solution seemed too perfect. “You’re saying that once it’s set up, we won’t feel it?”

“That’s exactly what I’m saying,” I nodded.

“Amazing!”

*For some basic data transfers, Zapier can be used, and it will set up the API for you. In those cases, anyone can set it up. For more complex APIs or for platforms that Zapier doesn’t work with, a software expert is needed.

(Originally featured in Mishpacha, Issue 1003)