California Observer

Dr. Connor Robertson’s Plain-English Guide to APIs for Non-Technical Founders

Dr. Connor Robertson's Plain-English Guide to APIs for Non-Technical Founders
Photo Courtesy: Dr. Connor Robertson

An API, according to Dr. Connor Robertson, is the most important concept in business automation that most non-technical entrepreneurs still cannot explain. It is also, in his framing, significantly simpler than it sounds. Anyone who has wondered how a CRM instantly knows a payment has been processed, or how a lead entered in one tool shows up automatically in another, is really asking about an API.

Robertson, an entrepreneur and strategic advisor based in Pittsburgh, defines the term in practical rather than technical language. API stands for Application Programming Interface, and in his explanation, it serves as a standardized way for one piece of software to send information to another and receive a response. He compares it to a phone line that two applications can call each other on, using a defined language they both already agree to speak. When a payment processor tells a CRM that a payment has been received, the exchange occurs via an API call, whether or not the business owner ever sees it.

Understanding this matters, in Robertson’s view, because APIs make meaningful business automation possible without custom software development. Nearly every tool a business already uses, its CRM, its email platform, its invoicing software, its accounting system, has an API of its own. That means, in principle, all of these tools are capable of communicating with one another. He points to no-code platforms such as Zapier and Make as tools that, at their core, make these API connections accessible to non-developers through a visual interface rather than a line of code.

That raises a natural follow-up question: when does a business actually need to interact with an API directly rather than through a no-code tool? Robertson’s answer is that, most of the time, it does not. No-code tools handle the underlying API calls on a business owner’s behalf. Direct API access becomes necessary, in this framework, only in a few specific situations: when a task requires logic or functionality that no no-code tool currently supports, when a business wants to reduce ongoing costs by removing a third-party subscription from the equation, or when what is being built is custom enough that visual tools introduce more constraint than they remove.

For times when direct developer help is genuinely required, Robertson offers specific advice on how that conversation should go. He suggests that a business owner will achieve far better results by describing what they want in terms of data and behavior rather than technical architecture. His recommended framing is to tell a developer plainly what information exists in one system, where it needs to appear in another, what event should trigger that transfer, and what should happen if the transfer fails. That kind of brief, in his experience, produces a far more useful outcome than an attempt to describe the technical implementation in unfamiliar jargon.

Robertson situates all of this inside a broader shift he calls the API economy. Nearly every major business software product today offers API access as a standard part of its offering, which means the infrastructure needed to connect a business’s tools already exists and is maintained by the vendors themselves. Nobody has to build that infrastructure from scratch. They have to configure it. That distinction, from building integrations to merely configuring already-existing ones, is what Robertson believes has put sophisticated automation within reach of any business owner who has a clear enough understanding of what they are actually trying to accomplish.

The larger point he returns to is that technical fluency is no longer the bottleneck it once was for a founder trying to connect their tools together. What matters more, in his framing, is clarity about the outcome a business owner wants, since the mechanics of achieving it, whether through a no-code platform or a short developer conversation, have become far more accessible than most non-technical founders assume.

About the author

Dr. Connor Robertson is an entrepreneur, author, and strategic advisor based in Pittsburgh. He is the founder of Elixir Consulting Group and host of The Prospecting Show. More about his work is available at drconnorrobertson.com.

California Observer

This article features branded content from a third party. Opinions in this article do not reflect the opinions and beliefs of California Observer.