“Open API” Is Not a Border Crossing: The Interoperability Myth
Vendors claim their API allows you to leave anytime. Try to move a terabyte of case history through a rate-limited REST endpoint and see what happens.
The Rate-Limit Blockade
The vendor’s CTO was drawing boxes on the whiteboard. “And here,” he drew a line connecting their cloud to our archives, “is our REST API. Full swagger documentation. You have total interoperability.”
He sat down, looking pleased.
“That is a lovely feature for a mobile app,” I said, remaining seated. “But let us discuss the Divorce Scenario. If we terminate this contract, I need to extract 500,000 case files, including their audit logs and version history. Based on your API rate limit of 1,000 calls per hour, that calculation suggests the extraction will take approximately four years.”
The CTO blinked. “Well, the API isn’t really meant for bulk migration…”
“Then you do not have an exit strategy,” I replied. “You have a retention strategy disguised as technology. This is a trade embargo on our own history.”
The Trap: The “Open” Mirage
The term “Open API” is frequently used to silence the concerns of the procurement officer. It suggests freedom. In reality, relying on an API for data sovereignty is like trying to move a library through a mail slot—one page at a time.
Vendors place “Tolls” on these roads:
- Throttling: They limit how fast you can pull data, making a full backup operationally impossible.
- Loss of Fidelity: The API often exposes the current state of the record, but hides the history. Who changed the file last year? That data is often locked behind the dashboard, inaccessible to the API.
- Pagination Hell: To scrape your own data, you must write complex scripts that navigate millions of pages. If the script fails at 99%, you start over.
If we cannot move the data in bulk, we are not customers. We are subjects.
The Exit Strategy: The Database Dump Clause
We no longer accept “API Access” as proof of portability. We demand Snapshot Sovereignty.
Our contracts now specify three requirements for the “Data Exit”:
- The “Hydrant” Protocol: We require a mechanism to download the full dataset (SQL dump or equivalent structured archives) over a secure connection, with no bandwidth throttling, within 24 hours of request.
- Schema Documentation: The vendor must provide the “Rosetta Stone”—the documentation that explains what
col_id_4492actually means. Data without a schema is a puzzle, not a record. - File Attachments: The export must include the actual binaries (PDFs, images) linked to the metadata, not just the URLs pointing to them.
[TO EDITOR: Illustration of a tiny pipe labeled “API” dripping water, next to a large open floodgate labeled “Bulk Export”.]
We do not ask for permission to access our data. We demand the physical capacity to move it. If the vendor cannot build a gate wide enough for us to leave, we will not enter.
FAQs
What is the difference between an API and a Bulk Export?
An API fetches one record at a time, often slowly. A Bulk Export dumps the entire database structure. You cannot migrate a city via API.
Why do vendors limit API speeds?
They claim 'stability,' but often it is 'retention.' If it takes 3 years to download your data, you will renew the contract for 3 years.
Does 'JSON format' guarantee we can use the data?
No. If the JSON schema is proprietary and undocumented, it is just a text file of gibberish. We need the dictionary (schema) too.