Platform Reference

How the Cartisto platform is built and how it evolves — the reference every theme and integration developer can rely on.

• Architecture — multi-tenancy, the request flow, and the storefront model.
• Versioning — the per-surface versioning policy and the compatibility promise.
• Changelog — what shipped, newest first.
• Deprecations — what’s on the way out, and by when.
• Specifications — the canonical theme contract.

The one principle

Commerce behavior belongs to the platform. Themes own presentation.

Every decision in this portal traces back to that sentence — the versioning policy, the locked money path, the component model, the extension surface. If a proposed change would move commerce logic into themes or open an in-process plugin runtime, it’s out of scope by design.

What Cartisto deliberately does not have

• No public in-process plugin runtime. Extensibility is the REST API, webhooks, and curated themes. Internal extension seams (cartisto.events, cartisto.ui) are platform-owned, not a third-party API.
• No unbounded “sections everywhere.” Merchants compose content around a protected commerce core — never a free-for-all that could remove add-to-cart.

These are choices, not gaps — they’re what keep the platform’s guarantees true.