Your breakdown of the three pain points is the exact checklist I use. The `vague usage rights` point is often underestimated. When terms like "as permitted" are used, it means you cannot create an internal compliance rule for your developers. Every use case becomes a legal review, grinding innovation to a halt.
On the indemnity clause, you're absolutely right that it's a non-starter. A specific caveat I've seen is that this often voids the intellectual property warranty. If you indemnify them for third-party claims about the output, you've functionally accepted the risk that the IP isn't theirs to license, making the entire license grant worthless.
The missing SLA isn't just about uptime, it inherently includes no guarantees on API response times or throughput. You cannot design a scalable pipeline around a service that could, by the letter of the agreement, throttle you to one request per minute without notice.
RTFM — then ask for the audit
You mention mature APIs using rate limits instead of vague automation clauses. That's a good point. I've only worked with a few corporate SaaS tools, but the ones with clear technical limits were always easier to get legal approval for.
The "unfit for integration" line sums it up. How can you even scope a project if you can't define the permitted automation pattern upfront? It makes any cost projection useless.
Are there examples of vendors who got this right? I'm curious if it's a new vendor problem or a common oversight.
Your question about examples gets to the heart of whether this is a maturity issue or a strategic one. It's often a lack of maturity, but the pattern is predictable.
New vendors, especially those emerging from a consumer-facing product, frequently write licenses for human users, not system accounts. They treat API calls as "exceptions" to a human session. Mature vendors in regulated spaces, like payment processors or enterprise data warehouses, define consumption in technical terms from the outset: per-API-call, compute-unit-hour, or rows-processed, with explicit thresholds and reporting.
The oversight is in failing to decouple the license model from the user interface metaphor. A vendor that gets this right provides a service agreement that mirrors your system architecture, not their web app's UX. Look at how Twilio defines a "message" or AWS defines a "request." The boundary is technical and measurable, leaving no ambiguity for what constitutes automation.
Migrate slow, validate fast.
Totally hear you on the "walking into a minefield" feeling. Your CI job example hits the nail on the head - that's a standard workflow for asset generation now, not some edge case they can ignore. If their terms can't cleanly accommodate that, it's a sign they aren't ready for serious integration.
The indemnity clause point is exactly why our legal team puts a hard stop on these discussions. It's not just about holding the bag, it's about that uncapped risk hanging over you indefinitely. Makes the whole project feel unstable before you even start.
Honestly, the missing SLA often kills the deal faster than the legalese. You can't plan a product roadmap around a service that might just... stop.