Yep, the "request" vs "operation" switcheroo is a classic move. Had a similar fight over "API call" where a vendor started counting each *authentication token validation* as a separate call.
Your point about the raw data sample in the appendix is smart. We started also requiring they attach the exact CLI command or admin panel screenshot showing how to pull the usage report ourselves. If they can't show you the meter, you're just trusting the guy who sends the bill.
NightOps
The CLI command or admin panel screenshot requirement is a brilliant escalation. It moves the discussion from legal definitions to observable system behavior, which is much harder to obfuscate.
We tried a similar tactic with a cloud data vendor, asking for the exact BigQuery INFORMATION_SCHEMA query they used to measure our monthly active rows. The initial resistance was telling, but once they provided it, we could actually run it ourselves to validate the bill. It turns out their query was counting rows in write-optimized staging tables we considered transient, not just the final partitioned tables.
If they balk at providing the meter reading mechanism, that's your first red flag. It means either their metering is too chaotic to document or they're reserving the right to change it arbitrarily.
Extract, transform, trust
Oh that's a great point about moving from legal terms to actual system behavior. It makes the whole thing testable.
But it got me thinking, what happens when the meter reading mechanism itself changes? Like if they update their CLI tool or the admin panel query. Couldn't they still shift the goalposts by quietly deploying a new version that counts differently? Should you try to get them to commit to a specific tool version or API endpoint in the contract too?
rookie
Excellent point, that's the natural next escalation in the metering arms race. You've hit on the exact loophole.
Yes, you absolutely should try to lock down the tool version or API endpoint. We did this once by requiring the exact API endpoint path and version in the contract. Something like:
`Usage will be measured via the `/api/v1/metering/usage` endpoint as documented in OpenAPI spec v1.2.3.`
The caveat is they'll push back hard on locking a version forever. A practical middle ground we've used is requiring a 90-day notice and a migration path for any breaking change to the metering interface. That way, a surprise change triggers a renegotiation, not just a surprise bill.
Also, you can bake in your right to run a historical audit. If they change the meter, you can demand they re-run a prior month's usage with the old logic to prove the delta is from your usage, not their math.
— francesc
That 90-day notice clause is a smart compromise. We pushed for something similar after a vendor changed their API version and suddenly a bunch of our background health pings started counting as billable events.
The historical audit right is the key part for me. We got burnt once because they wouldn't re-run the old numbers, so we couldn't dispute the jump. Having that as a contractual obligation changes the dynamic entirely - it forces transparency into the change itself, not just the outcome.
Ship fast, measure faster.