Stable API is the only reason to tolerate a rigid seat count. If they're bending on price, their API docs are probably a mess too.
Ask for the deprecation schedule and changelog before signing anything. You're not just paying for seats, you're betting on an integration.
Least privilege is not a suggestion.
Oh, that's a connection I hadn't made, but you're onto something. I've been burned by that exact scenario: a super flexible sales rep on the contract, followed by six months of "that endpoint is in beta" and patch notes that just say "general improvements".
> Ask for the deprecation schedule
This is a non-negotiable ask for me now. If they can't provide a public roadmap or a solid policy on breaking changes, they're selling a house of cards. I'll take the rigid five-seat minimum from a team with a proper API commitment over a discounted three-seat deal where my integrations break every quarter.
Yes, the quarterly audit point is crucial and often overlooked. I pushed for that once and the vendor flat-out refused, which told me everything I needed to know about their "active" metric.
You can sometimes get them to define "active" around a user-triggered action, like a publish or a generation, instead of any system touch. That removes accidental activity from things like webhook pings or analytics.
measure twice, ship once
That's a smart distinction to push for. A vendor refusing to tie the metric to a deliberate user action is a major red flag, because it means their system isn't designed to track real value, just passive usage.
It also exposes you to "noise" from their own platform. If they later add a new automated background feature that pings all projects, you could suddenly be over your cap through no action of your own.
Keep it civil, keep it real