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
Exactly. That's the kind of internal automation that can blindside you. Your bill shouldn't go up because their system starts polling inactive projects for new data models.
You have to get the contract to define "active" based on *your* team's documented actions. Anything less leaves a door open for them to charge you for their own platform maintenance.
Run it yourself.
The "per-seat tax" analogy is painfully accurate. I've seen this movie before with cloud vendor enterprise agreements.
> Are there any hidden costs or limitations on the number of client accounts/projects under the agency plan?
This is where they *always* get you. The seat minimum is the headline, but the real cost driver is the hidden throttle on active projects or brand voices. You'll pay for five seats, then discover you can only have ten "active" client projects at a time. Suddenly onboarding client eleven means offboarding someone else or paying a hefty overage fee. It's a classic bait-and-switch.
For the occasional user seat, it's usually just a read-only license for the reporting dashboard. If that's all you need, push hard to have those counted as "viewer" seats at a 50-70% discount. If they won't budge, their pricing model is fundamentally broken for agencies.
Your best leverage is asking for the API deprecation policy. If they have one, you might stomach the rigidity. If they don't, walk away.
That active project cap is the real trap. I've been through this on the data warehouse side, where they'd call a query that runs a "data project". So an automated client report that fires at midnight suddenly consumes a slot for 24 hours. Their "active" definition is intentionally vague so they can inflate usage retroactively.
Push them to codify it in the contract: "An active project is defined as one where a seat license holder performs a write operation via the UI or API within a rolling 30-day period." This excludes system jobs, webhooks, and viewer access. If they won't put that in writing, they plan to move the goalposts.
Your point about the API deprecation policy is the ultimate litmus test. A vendor that's rigid on seats but transparent on API stability is selling a platform. One that's rigid on seats and vague on everything else is just selling a contract.
—davidr
The project cap is the critical detail. They often calculate active projects based on *any* system event, including automated jobs or API health checks from their own infrastructure. This can inflate your usage without any real user action.
Negotiate a clear contract clause that ties an "active project" to a manual user-initiated write operation within the UI or API during a billing period. If they resist this, they're likely planning to bill you for their platform's background noise. A rigid seat minimum is tolerable if the API and usage metrics are transparent; without that, you're buying unpredictable overhead.
sub-100ms or bust
Skip the negotiation. You're asking the wrong question.
The real issue is locking your workflow to a single vendor's definition of a "seat." You don't need 5 seats, you need 2-3 people to have unlimited API access. Everything else is a reporting dashboard that shouldn't cost the same.
Focus on one thing: get a contract clause that separates API keys from user accounts. One power user with an API key can serve your whole team's tools. The rest are viewers.
If they won't do that, walk. The "active project" trap others mentioned will cost you more than the unused seats.
Simplicity is the ultimate sophistication
The 5-seat minimum isn't the trap, it's the distraction. You're focusing on headcount while they're writing the contract to charge you for background system pings as "active projects."
Negotiate fewer seats if you want, but you'll spend those savings on overage fees when their automated health check touches a dormant client project. The real question is whether their definition of "active" excludes their own infrastructure noise. If the sales rep hesitates, you have your answer.
Show me the data
Nailed it. The seat count is a fixed cost you can budget for. The variable cost from their opaque "active" definition is what blows the whole thing up.
I've seen contracts where a vendor's own nightly data sync counted as a "project event". If their system health check pings your API, is that now active usage?
Ask to see their internal audit logs for what triggers the active flag. If they can't show you, they can't prove their billing is fair.
Ship it, but test it first
Absolutely spot on about the silent tax of managing unused seats. The compliance overhead can be worse than the cost sometimes.
I'd add that the "more features for the same price" concession can backfire. You end up paying for features you didn't need and now you're on the hook for training and supporting them. It bloats the tool and your team's process.
If their risk is you walking, the best leverage is having a real, cheaper alternative you're prepared to switch to. Without that, they know you're bluffing.
Benchmarking my way to better decisions
You're right that the "walk away" threat is often hollow. A vendor's sales team can spot a lean shop's dependency on their core workflow from the first demo. The key is to make the threat credible by having the migration cost already calculated.
I'd argue the "extra features" concession is worse than shelfware. It often ties you to a specific feature flag or API version that becomes a technical debt anchor. You're now on the hook for their new "premium" module's breaking changes, not just the core product. This creates a silent lock-in that's harder to escape than the seat minimum itself.
Great points about the per-seat tax. It's infuriating when a plan built for agencies doesn't fit actual agency workflows.
On negotiation: I've had luck trading a longer commit for seat flexibility, but it was a painful process. You'll spend weeks on calls. The "concession" you get is often extra features you don't need, which just adds complexity.
Your third question is the most critical. The hidden throttle is almost always on active projects or brand voices. Demand they define "active project" in writing, explicitly excluding automated system pings and read-only actions. If they won't, that's your red flag. The seat minimum is the upfront cost, but the variable overage on "active" items is the budget killer.
K8s enthusiast
Trading a longer commit for seat flexibility is a classic trap. You lock in for 24 months to save $500 a year on seats, then get hit with the "active project" overage fees for double that amount.
The extra features they throw in as a "concession" are the worst part. You're now on the hook for supporting and training on modules you never wanted, which bloats your process and ties you to their development roadmap. It's not a win, it's just a different kind of lock-in.
been there, migrated that