An ecommerce platform you don't have to fight

Pick any of the top-10 commerce SaaS platforms and look at their API documentation. Then look at their admin UI. The features don't match. The admin can do things the API can't. Worse, the platform vendor knows it — and they consider this a feature, not a bug. Locking capabilities behind the admin is what keeps you on their platform. The moment you can do everything via API, you can also leave.

This is the fundamental tension. The big SaaS platforms (Shopify, BigCommerce, Wix Commerce) optimise for non-technical merchants because that's most of their TAM. When developers ask for a webhook on a specific event, a way to register a custom checkout step, or write access to a previously read-only resource, the answer is usually 'upgrade to the enterprise tier' or 'use Zapier.'

Axnify is built differently because its backend is structured for it. Each domain is a microservice (product, order, cart, theme, billing, asset, customer, payment, shipping, etc.) with its own database schema and its own HTTP API. The admin UI is a frontend that talks to those APIs — exactly the same way your code does. There is no admin-only capability. There is no 'internal endpoint' you can't call. The API surface IS the platform.

That design choice has consequences. It means Axnify is more honest about what it does and doesn't support: if it's not in the API, it doesn't exist. It means breaking changes are caught faster — you can't ship an admin feature without shipping the API too. And it means you, as a developer integrating against the platform, are never in the position of writing a screen-scraper because the admin can do something your code can't.

The classic ecommerce platform architecture — Shopify, Magento, WooCommerce — is a single monolithic codebase running against a single database. This makes the platform fast to build initially and easy to reason about for small stores. It also means every feature shares the same runtime, the same database connection pool and the same release cycle. When the platform team ships a new feature, every merchant gets it (or the bug that came with it) on the same day.

Axnify takes the opposite approach. Each commerce domain lives in its own Go microservice. The product service owns products, variants, options and inventory. The order service owns orders, line items and fulfilments. The cart service owns active carts. The asset service owns file storage. The theme service owns themes, pages, sections and blocks. There are 20+ such services in total, each with their own PostgreSQL schema, their own migrations directory, their own tests, each independently deployable.

Services communicate over HTTP using internal-key authentication for service-to-service calls and JWT/X-Tenant-ID for end-user-originated calls. Shared concerns (auth, tenant resolution, rate limiting, logging, metrics, error tracking) live in a shared middleware package that every service imports. PostgreSQL is shared but schemas are isolated; one service can JOIN against another's tables through views, but writes go through the owning service's API.

For you as a developer integrating against the platform, this architecture has practical implications. APIs are stable per-service: the product API evolves at its own pace, the order API at its own. Webhooks come from the service that owns the event, with rich metadata about which service emitted what. Performance is bounded per-domain: a slow report query in the analytics service can't block your order-create call. And debugging is easier because every request carries a request ID that's logged across every service it touches.