Per-store billing, and the customers who asked for it
Multi-storefront retailers kept asking for something our pricing model could not express. So we changed the model.
We have spent seven years insisting that one call is one call and pricing should be a single number multiplied by volume. A category of customer has been patiently explaining why that does not work for them, and they were right.
The mismatch
A retailer running eleven storefronts across four platforms does not think in requests. They think in stores. Their costs scale with stores, their org chart is arranged by store, and when they add a market they want to know what that market costs — a question our invoice could not answer.
Worse, our model actively penalised the thing they needed most. Keeping eleven storefronts consistent means continuous reconciliation, which is a lot of requests, most of which confirm that nothing has changed. We were charging for diligence.
What we changed
The Multistore API is priced per connected store per month, with request volume included rather than metered. Add a store, the invoice goes up by one store. Remove it, it goes down.
That is the whole model, and its virtue is that a non-technical person can predict it. The finance team stopped asking engineering to explain line items, which was a recurring cost nobody had counted.
The part that was harder than pricing
Per-store billing only makes sense if a store is a real object in the system rather than a label. That meant stores needed their own identity: their own API key, their own usage record, their own rate limit, and their own place in the dashboard.
The per-store key turned out to be the feature customers talk about most. When a contractor's engagement ends you rotate one key, and the other ten storefronts do not notice. Under a single account-wide key, that same event means auditing every integration you have ever built.
What we are not doing
We are not moving anything else to this model. For a lookup API, per-request is the honest unit and per-seat pricing would be arbitrary.
The lesson we take is narrower than "our pricing was wrong". It is that the billing unit should match the unit the customer already manages. For most APIs that is the request. For this one it is the store.