Overview

A map of Commerce Layer's resources and how they work together

A data model is the backbone of any API-driven platform. It defines the resources that power your application and the relationships connecting them. Think of it as a blueprint showing how different entities interact and depend on each other to deliver functionality.

Commerce Layer's data model represents years of refining how commerce should work in a headless, composable architecture. It shows how products, inventory, orders, customers, and payments work together, handling the complexity of modern multi-channel retail while remaining flexible to your unique business needs.

Why a data model matters

Understanding resource relationships is essential for building effectively. When you know that a market connects price lists, inventory models, and shipping methods, you can quickly configure multi-country operations. When you understand how SKUs, bundles, and stock items interact, you can design sophisticated product catalogs with confidence.

The data model helps you plan integrations, optimize API calls, and troubleshoot issues. Instead of discovering relationships through trial and error, you see the complete picture upfront and make informed architectural decisions.

Why we make it public

Transparency is core to how we operate. Developers should have complete visibility into the system they're building on. By documenting our data model, we enable you to design your commerce architecture with full knowledge of capabilities and constraints, understand the impact of decisions before writing code, build integrations that work with the platform's design, and evaluate whether Commerce Layer fits your use case.

This documentation includes E-R diagrams for major resource groups, showing relationships, key attributes, and data flow. Whether you're architecting a new solution or extending an existing one, this guide helps you understand not just what Commerce Layer does, but how.

Each page focuses on a specific domain. Start with areas most relevant to your immediate needs, but don't forget to explore related domains — commerce operations are interconnected, and powerful implementations leverage relationships across multiple resource groups.

Reading the diagrams

The entity-relationship diagrams use standard notation to show how resources connect. Each line between resources represents a relationship, with symbols indicating cardinality:

• 1 — exactly one (required)

• N — many

• 0 — optional (can be zero)

Common patterns include 1 — N (one-to-many), 1 — 1 (one-to-one), 0-1 (zero-or-one), and N — N (many-to-many). For example, a market has many price lists (1 — N), while a price list can be optionally associated with one or more price list schedulers (0-1 — N).

The resource(s) each page focuses on and the connections to their direct relationships are highlighted with an accent color: