Multistore: one integration, every storefront
Three years after per-store billing, the API it was built for is our fastest growing listing. What we learned building for retailers.
We introduced per-store billing in 2022 for a category of customer our pricing could not express. The Multistore API that came out of that work is now the fastest growing listing on the platform, and the lessons are worth writing down.
The problem, restated
A retailer with eleven storefronts across four platforms has the same catalogue in eleven places and no reliable way to keep them consistent. Each platform has its own API, its own field names, its own idea of what a product variant is, and its own rate limits.
The work of reconciling them is continuous, unglamorous, and almost always done by a script one person wrote and everyone is afraid to touch. We have seen that script at a dozen companies. It is always the same script.
What we built
One set of endpoints for catalogue, inventory, orders and pricing, with connectors underneath for each platform. The response shape is identical regardless of what is behind it, which is the entire value — the caller writes one integration instead of four.
What we do not do is pretend the platforms are the same. Where a concept genuinely differs, the field mapping is explicit and configurable rather than guessed at. Our earlier instinct, back in 2015, was to normalise everything into a house schema, and we learned then that it collapses on contact with the sixth provider.
Per-store identity
Each connected store gets its own API key, its own usage record, its own rate limit, and its own line on the invoice.
The key is the part customers talk about. Rotating credentials for one storefront does not touch the other ten. When a contractor's engagement ends, that is one revocation rather than an audit of every integration.
Per-store usage charts have been unexpectedly valuable for debugging. Several customers have found runaway retry loops in their own code because one store's line on the chart diverged from the rest — a problem their own monitoring had not surfaced.
What surprised us
Seasonal churn. Retailers connect and disconnect stores far more than we expected — pop-ups, market tests, holiday storefronts. Billing had to follow that gracefully, and disconnecting a store had to preserve its history so reconnecting three months later does not lose anything.
We got that wrong at first. A disconnected store used to lose its usage history, and the first customer to reconnect one in January discovered it in the worst way. History is now retained for twelve months after disconnection, at no charge.
What is next
More platform connectors, and better conflict resolution when two platforms disagree about the same product. The field mapping handles most cases and the long tail is genuinely hard. That is the work for next year.