“We have an open API” does not answer the question

Over two days in September we checked fourteen software houses — care, law, freight, HR, property. Not against marketing copy, but against the vendors’ own interface documentation.

Two of them can do what we need. That sounds like a verdict on an industry. It is mostly a verdict on a question almost everyone asks wrongly.

2 of 14

The question that counts

Whether a system has an interface is the second most important thing we need to know. The most important is:

Can you ask it about a phone number?

The distinction sounds pedantic and is not. It decides whether a name is on screen when the phone rings.

Three ways it fails

After fourteen houses this is no longer coincidence but a pattern. Where it does not work, it fails in one of three ways.

One: the interface is built for something else

Freight software answers “where is the shipment?”, “what does the freight cost?”, “which slot is free?”. Addresses do not appear — not because someone forgot them, but because a shipment API is not an address database.

The same with shipping platforms: the recipient’s number is in the record, because the courier needs it. The shipment list is still filtered only by date, status and parcel ID.

Two: the data is there, just not queryable

This is the dangerous one. It looks like a hit: documentation present, phone fields present, all green. Only a look at the filter list shows that you cannot ask.

• A well-known accounting package filters contacts by name, e-mail and customer number. The phone number is in every response — as a filter it does not exist.
• A widespread HR system knows exactly five parameters on its employee endpoint. None of them is a phone number.
• A second HR system knows seven. Also none.

Guessing here builds an integration that reports no error and finds nothing.

Three: the industry has a standard — and it is not a web service

In medical practices it is called GDT, for insurance brokers BiPRO and GDV. “The industry has standards” sounds like open doors. What is meant is one-way data delivery — a format, not a service you can question.

The case that annoyed us most

Two large ERP products from the same vendor can filter — but their documentation says explicitly that an OR cannot span two different fields.

So a number search there can query the landline or the mobile. Never both. Technically flawless, practically worthless — and the failure does not report itself, it simply says “contact not found”.

What a vendor would have to change

Almost always: one parameter. Not a project, not an architecture, not a migration. One more filter on an endpoint that already exists.

With a booking system for sports clubs we worked it out: the member endpoint already returns the number, all that is missing is the ability to filter by it. One line of documentation, one database index.

Why we still do not talk down the industry

Anyone selling software to care services, law firms and property managers has no developers as customers. A public interface costs maintenance and initially brings that business model nothing. This is not negligence, it is arithmetic.

Which is exactly why our offer is interesting there: we are the developers these houses do not have. They only need to tell us how to ask their software about a phone number — we build the rest.

And if the answer is no, that too is information. A no removes a vendor from the list instead of leaving them on it as an open question. That is worth more than a maybe.