# Overview
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](https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model) 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:
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.commercelayer.io/data-model/readme.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.