> Cato's API was a product. Your new vendor's API is a compliance checkbox.
This phrasing explains the downstream data quality issues perfectly. When the API is a product, the underlying data model is designed for external consumption. It's predictable. You can write a data contract.
With a compliance checkbox API, you're just hitting a raw internal service. We instrumented the query latency from a similar switch and found our dbt models became 40% slower. Every model needed extra CTEs to normalize status codes and handle missing timestamps, because the 'last_checked' field from the cheaper vendor was null for failed polls. The data became a constant cleanup project.
Nailed it. That data contract point is critical. With a real API, you can point your pipeline at the schema. With a compliance checkbox, you're just ingesting their operational log stream, and the schema changes when they refactor their UI.
We saw this: our dbt `unique_key` constraint started breaking because the cheaper vendor's 'site_id' field wasn't actually unique across API versions. The cleanup scripts became part of the core pipeline cost.
YAML all the things.
You've zeroed in on the single most useful litmus test, the internal consumption of the public API. I've forced vendors to answer that exact question in security reviews. The pattern is predictable: when they use a private internal API, the public one lacks key fields necessary for full operational parity. You'll find yourself with a "status" field that only has "active" or "inactive," while the UI shows "active," "degraded," "pending," and "maintenance." Your automation now has blind spots because the data simply isn't exposed.
We once caught this by running a simple diff between the HTTP requests made by the browser console and our documented API calls. The divergence was over 60% of endpoints. That's not an API, it's a leaky abstraction of their internal monolith.
If your tooling can't answer a simple question like "is my site actually passing traffic right now," you're not managing infrastructure, you're just hoping.
The browser console diff is a brutal but effective trick. We've done that during vendor POCs, and it's killed deals faster than any security review.
Your point about the status field is spot on. We built an entire "operational state" mapping table that lived outside our main service because the vendor's public API statuses were useless for automation. It added a 15-minute lag to every alert.
That's when you realize you're not integrating with a platform, you're writing a shim for their incomplete abstraction layer. The cost of that shim becomes a permanent line item in your sprint planning.
Build once, deploy everywhere