Yes, There Is an API. Does It Carry the Numbers You Need?

Often not the ones you are asking about. "Does it have an API?" gets a yes almost every time, and the yes answers a smaller question than the one you meant.

This is the sixth pattern in Friction, Found, our series on the friction we see most often inside growing companies.

What does "there is an API" actually promise?

An API is a door. It lets other software read and write certain records in a system, the ones the vendor chose to expose. It does not promise that the records you care about are behind that door.

Picture an owner who wants one weekly view of the business: work completed, money collected, money still owed. The core software has a certified API. Good news, until someone reads what it carries. The operational records are all there: the jobs, the schedule, the people. The money side lives somewhere else, in a part of the system the API does not reach.

So the yes was true. It was a yes to a different question.

Why are the numbers you want so often outside it?

Because reporting is weak in a lot of software categories, and the API was built for the work, not for the owner's questions about the work.

Look past one vendor and across the whole category, and the same picture tends to show up. Even the large analytics companies that serve that kind of software often settle for a nightly export rather than a live connection. That tells you something. When the biggest specialist in the space cannot get a clean live feed of the money side, the gap belongs to the category, not to one vendor.

That matters for the plan. If you think the problem is one vendor, you shop for a better vendor. If the problem is the category, switching buys you a new login and the same gap.

What should you ask before anyone says "integration"?

Four questions, before any vendor call:

• Which numbers do you need, exactly? Name them. "Better reporting" is not a number.
• Where does each one live today? Which system, which screen, which export.
• Which version does the team trust? If the bookkeeper and the operations lead quote different figures, find out why first.
• How fresh does it need to be? Most owners who ask for live data are well served by this morning's numbers.

The answers usually shrink the project. We walked through the trust question in what a single source of truth actually requires.

Why do the words matter as much as the connection?

Because two people can use the same word for two different businesses.

Picture an owner who uses "partner" and "vendor" interchangeably. Ask what each one means, and they turn out to be two different business models. With one, money flows out as a commission. With the other, money flows in as a fee. Build the system on the assumption that they are the same, and you build the wrong thing, cleanly.

That is a strategy question wearing a technical costume. It has to be decided before it can become a field in a system. Ask for the owner's own definitions before anyone scopes the work.

How do you prove the plan before you build it?

Test the riskiest piece first, on real material, before a single screen exists.

A small trucking carrier is a good example. The riskiest part of that build was reading the incoming paperwork correctly, so we proved that first, on a stack of real documents. The samples corrected an assumption about who the customer actually was before it got built into anything. The finished system took the back office from about 10 hours of admin a week to 2 or 3.

A spec is a hypothesis until real documents run through it. The same goes for an API. Pull a week of real records through it before you plan a report on top of it.

What does an honest scope look like?

Smaller than the sales conversation, and more useful.

It starts with a short discovery step: confirm which numbers matter, where they live and how fresh they need to be. Then it is often an export-and-report pipeline. The system exports what it holds on a schedule, a small piece of work joins it with the money side, and the owner gets the weekly view in one place. Nightly is usually fresh enough.

It also leaves room to grow. Once the weekly view is in use, the team will know which one number they wish were live, and that is a much smaller project to scope than everything at once.

It is less exciting than "full integration." It also works, and it can be running in weeks. We compared the bigger route in automation platform or fix the handoff.

Where should you start if you see this in your own company?

Start before the API. Write down the three numbers you would check every Monday if you could, and next to each one, where it comes from today. That page is the process. Once it exists, the API question gets easy: either the door leads to those numbers or it does not. Process first, then the tool.

If you want help with that, bring it to a Friction Audit. Give us 45 minutes and we will map where your numbers live, what your systems can and cannot hand over, and what the smallest honest build looks like. The Leverage Map that comes out of it is yours to keep.