# Cimplify Docs > Type-safe SDK and REST API for the Cimplify commerce platform: catalogue, cart, checkout, scheduling, subscriptions, hosted checkout (Pay), and embeddable Elements via Cimplify Link. Notes for agents: - Every doc URL has a Markdown twin at `/llms.mdx` — e.g. `/docs/sdk/cart` → `/llms/docs/sdk/cart.mdx`. - The SDK is published as `@cimplify/sdk` on npm. - All client methods return `Result` and never throw. - `/checkout` request body is FLAT (top-level fields), not wrapped. - Scheduling endpoints accept `variant_id` for per-variant overrides. ## Pages - [Agent prompts](https://cimplify.dev/llms/docs/agent-prompts.mdx): Copy-paste prompts for the most common Cimplify workflows. Drop any block into Claude Code, Cursor, or any MCP-aware agent. Fill the angle-bracket placeholders and run. - [API Reference](https://cimplify.dev/llms/docs/api-reference.mdx): Cimplify storefront APIs use `/api/v1/*` and JSON request bodies. Public browser calls use `cpk_*` keys; server calls use `csk_*` keys; customer-scoped calls attach bearer session tokens. - [Choosing a checkout integration](https://cimplify.dev/llms/docs/checkout.mdx): Cimplify ships five layered ways to take a payment. Pick the highest tier you can; each step down the list trades a few minutes of integration time for more control. All five eventually reach the same backend checkout endpoint. - [CLI](https://cimplify.dev/llms/docs/cli.mdx): Every storefront workflow (scaffold, develop, deploy) runs through the Cimplify CLI. - [Docs](https://cimplify.dev/llms/docs.mdx): Build storefronts, embed checkout, and let agents transact on Cimplify. The SDK, hosted checkout, and UCP all share one backend and one data model. - [Cimplify Link](https://cimplify.dev/llms/docs/link.mdx): Link is Cimplify's shopper identity and saved-details layer: saved addresses, saved payment methods, cross-merchant sessions, and checkout acceleration. - [MCP server](https://cimplify.dev/llms/docs/mcp.mdx): Cimplify exposes a Model Context Protocol server at api.cimplify.io/mcp. Agents (Claude Code, Cursor, ChatGPT Connectors, Continue, Goose) speak streamable HTTP per the MCP 2025-11-25 spec and drive every CLI workflow as typed tool calls: no shell-out, no help-text parsing, no stdio bridge required. - [Cimplify Pay](https://cimplify.dev/llms/docs/pay.mdx): Cimplify Pay is the hosted-checkout product. You create a session (or a payment link) on your server; the customer is redirected to `pay.cimplify.io`, which renders the full checkout flow on Cimplify infrastructure; on completion they bounce back to your `success_url`. It's the same iframe-based checkout you can embed directly; Pay just ships it on a Cimplify-owned domain so you don't have to. - [Quickstart](https://cimplify.dev/llms/docs/quickstart.mdx): From zero to a working storefront in 60 seconds. `cimplify init` scaffolds a Next.js app wired to the local mock; the same code points at your live business when you bring keys. - [TypeScript SDK](https://cimplify.dev/llms/docs/sdk.mdx): Type-safe wrapper around the Cimplify REST API. Single dependency, browser-safe, framework-agnostic core, with a React layer and a Server Components layer on top. - [Storefront templates](https://cimplify.dev/llms/docs/templates.mdx): Six production-shape Next.js storefronts you scaffold with one command. Each one ships with cart drawer wiring, mock-seeded data, a brand-as-config layer, and pre-baked test suites, so the loop from `init` to `deploy` stays inside an afternoon. - [Testing](https://cimplify.dev/llms/docs/testing.mdx): The SDK ships an in-process Hono mock that mirrors the production lens, plus pre-baked vitest suites and zod schemas as the single source of truth. Boot the mock, run the suites, get a 30-second feedback loop: no live API, no shared state. - [TL;DR: zero to production](https://cimplify.dev/llms/docs/tldr.mdx): Ten commands from an empty shell to a live storefront at a custom domain. The full developer journey through the Cimplify CLI in one page. - [Universal Commerce Protocol (UCP)](https://cimplify.dev/llms/docs/ucp.mdx): A signed, capability-discoverable protocol AI agents use to browse, price, check out, and pay across any Cimplify business with verifiable consent. - [Activity](https://cimplify.dev/llms/docs/api-reference/activity.mdx): The activity API records lightweight session signals (product views, searches, cart events) so that the storefront can show relevant recommendations, intent-based incentives, and contextual messages. Every call is scoped to the active session token. - [Storefront Auth](https://cimplify.dev/llms/docs/api-reference/auth.mdx): Raw customer OTP endpoints on the storefront API. New storefronts should prefer SDK OAuth sign-in; these endpoints remain available for direct API integrations. - [Cart](https://cimplify.dev/llms/docs/api-reference/cart.mdx): The cart is server-owned and bound to the caller’s session. Items are added by `item_id` with an optional `variant_id` and add-on selections. The same cart is read on the storefront and on checkout; there is no client-side cart sync. - [Catalogue](https://cimplify.dev/llms/docs/api-reference/catalogue.mdx): The catalogue surface covers everything visible to a shopper: products and variants, categories, collections, bundles, composites, and the modifier groups (add-ons) attached to them. All endpoints live under `/api/v1/catalogue` and accept an optional `location_id` query parameter for location-specific pricing and availability. - [Checkout](https://cimplify.dev/llms/docs/api-reference/checkout.mdx): Convert the active cart into an order, run payment, and return everything the caller needs to confirm or redirect. The body is **flat**: fields like `cart_id`, `customer`, and `payment_method` sit at the top level. There is no `checkout_data` wrapper. - [FX](https://cimplify.dev/llms/docs/api-reference/fx.mdx): Indicative FX rates and lockable cross-currency quotes. Pass the resulting `quote_id` as `fx_quote_id` on `/checkout` to settle in a non-cart currency at the locked rate. - [Inventory](https://cimplify.dev/llms/docs/api-reference/inventory.mdx): Stock and availability lookups, scoped per location. Inventory is tracked at either the product or the variant level depending on the product’s `inventory_type`. - [Link API](https://cimplify.dev/llms/docs/api-reference/link.mdx): /v1/link/*: customer-scoped Link API for saved addresses, saved mobile money, preferences, sessions, and cross-merchant account data. - [Orders](https://cimplify.dev/llms/docs/api-reference/orders.mdx): Read and manage orders created by checkout. Authenticated customers get their own orders; guests can access individual orders by passing the order’s `bill_token` as a query parameter. - [Places](https://cimplify.dev/llms/docs/api-reference/places.mdx): Address autocomplete and place lookup, fronted by Google Places. Reuse a `sessionToken` across consecutive autocomplete calls and the final details call to keep billing on a single Places session. - [Scheduling](https://cimplify.dev/llms/docs/api-reference/scheduling.mdx): Surface available time slots, create bookings via the cart, and manage existing bookings. As of 0.44.30 slot and availability lookups are **variant-aware**: pass `variant_id` when a service has per-variant duration, buffer, or capacity overrides. - [Storefront assets](https://cimplify.dev/llms/docs/api-reference/storefront-assets.mdx): Business-scoped asset surface for storefront media: upload, list, inspect, and delete CDN-hosted files (images, videos, 3D models, fonts, PDFs). The CLI's `cimplify assets` wraps this. - [Subscriptions](https://cimplify.dev/llms/docs/api-reference/subscriptions.mdx): Read and manage the authenticated customer’s subscriptions. All endpoints require an active customer bearer session. - [Support](https://cimplify.dev/llms/docs/api-reference/support.mdx): Customer-facing support / chat-widget API. Each session has exactly one widget conversation; the server resolves it from the session identity, so callers never have to track a `conversation_id`. - [Uploads](https://cimplify.dev/llms/docs/api-reference/uploads.mdx): Two-step presigned upload flow. `init` returns a short-lived URL the client PUTs the file bytes to directly; `confirm` finalises the upload and returns the canonical CDN URL. - [Webhooks](https://cimplify.dev/llms/docs/api-reference/webhooks.mdx): Subscribe a server endpoint to lifecycle events emitted by Cimplify. Webhook administration is a server-side surface; all calls require a secret API key (`csk_…`) on `X-API-Key`. - [Appearance API](https://cimplify.dev/llms/docs/checkout/appearance.mdx): Cimplify checkout accepts an `appearance` object that controls theme, accent color, font, and corner radius. The same shape works for hosted Pay and embedded checkout. - [Drop-in checkout (hosted Pay)](https://cimplify.dev/llms/docs/checkout/drop-in.mdx): The fastest path to a paid order: create a checkout session on your server, then redirect the customer to the URL it returns. Cimplify hosts the entire checkout UI at `pay.cimplify.io/s/` (auth, address, payment method, compliance). You get a webhook (or success-URL redirect) when payment lands. - [CimplifyCheckout (React)](https://cimplify.dev/llms/docs/checkout/elements.mdx): Mount the Cimplify checkout iframe from React. This is the recommended embedded checkout path for agent-built storefronts and custom merchant sites. - [Embedded checkout iframe](https://cimplify.dev/llms/docs/checkout/embedded.mdx): Mount the same checkout UI as Cimplify Pay on your own domain. Raw iframe embedding is possible, but saved-details sign-in requires an OAuth bridge; most storefronts should use the SDK controller. - [Headless checkout](https://cimplify.dev/llms/docs/checkout/headless.mdx): Drive the checkout API directly. No iframe, no Cimplify-rendered fields; every screen, every input, every microcopy is yours. Use this when the iframe's look or layout can't accommodate your brand, or when you're building a non-web surface (native app, kiosk, voice). - [Vanilla checkout](https://cimplify.dev/llms/docs/checkout/vanilla.mdx): The framework-agnostic checkout surface. Use this from Vue, Svelte, plain HTML, or anywhere React wrappers are not the right fit. The same CimplifyElements controller backs ``. - [cimplify assets](https://cimplify.dev/llms/docs/cli/assets.mdx): Manage storefront brand assets (hero images, product photos, videos, 3D models, fonts) on the Cimplify CDN. `upload` is content-agnostic up to 50 MB per file; `ls` and `rm` are server-backed so the same view works from any machine. - [Component registry](https://cimplify.dev/llms/docs/cli/components.mdx): 67 ejectable components ship in the registry. `cimplify list` shows every component; `cimplify add ` copies one's source into your project. After ejection it's yours; you stop receiving SDK updates for that component, in exchange for full control over JSX, state, and behavior. - [Deploys & projects](https://cimplify.dev/llms/docs/cli/deploy.mdx): Create a project, link your CWD to it, and ship. Every deploy is a git SHA + a build; rollbacks are just re-deploys of an older SHA. - [cimplify doctor](https://cimplify.dev/llms/docs/cli/doctor.mdx): Run 14 pre-flight checks across your storefront and the linked project. Each row reports a verdict (`ok` / `warn` / `fail` / `skip`) and a fix hint. Exits `1` on any fail so CI can branch on `$?`. - [Domains](https://cimplify.dev/llms/docs/cli/domains.mdx): Domains live at the **business** scope: add and verify them once, then attach them to one or more projects per env (`preview` or `production`). One verified domain can serve any project in your business. - [Env vars](https://cimplify.dev/llms/docs/cli/env.mdx): Manage environment variables for the linked project across three scopes: `development`, `preview`, `production`. Push your `.env.local` in one command, or mutate single keys with `add` / `rm`. - [cimplify explain](https://cimplify.dev/llms/docs/cli/explain.mdx): Print canonical guidance on Cimplify concepts (cart, products, bundles, composites, services, errors, exit codes) straight from the terminal. 20 topics, bundled into the CLI binary at build time, no network calls. - [cimplify init](https://cimplify.dev/llms/docs/cli/init.mdx): Scaffold a working Next.js App Router storefront from one of seven industry templates. After `bun install`, `bun dev` boots the local mock API alongside Next, and you have a real shop in 60 seconds. - [Inspect](https://cimplify.dev/llms/docs/cli/inspect.mdx): Read-only snapshot of a storefront's catalogue, brand, and merchandising state, for humans at the terminal and agents over `--json`. - [cimplify introspect](https://cimplify.dev/llms/docs/cli/introspect.mdx): One-shot snapshot of the current storefront (auth, project link, brand, mock seed, env keys, git) in one structured envelope. Pure local: zero API calls, runs in milliseconds, designed for agents that need to orient in a fresh directory. - [cimplify login](https://cimplify.dev/llms/docs/cli/login.mdx): Authorize the CLI to talk to your Cimplify business. The default flow is browser-first OAuth Authorization Code + PKCE on a loopback redirect: no key paste, no shell history, no phishing surface. `--api-key` is the headless / CI escape hatch. - [cimplify mock](https://cimplify.dev/llms/docs/cli/mock.mdx): Boots an in-process Hono server that mirrors the production Cimplify API (~99% parity) with seeded data. The mock is the oracle for testing and local development; every scaffolded storefront wires `bun dev` to start it alongside Next.js. - [Repos](https://cimplify.dev/llms/docs/cli/repo.mdx): Every project deploys from a git repo. Provision a Cimplify-managed repo, or connect your own GitHub/Gitea remote. `cimplify deploy` pushes to whichever is attached. - [API Keys](https://cimplify.dev/llms/docs/concepts/api-keys.mdx): Cimplify uses three families of credentials: **public keys** for the browser SDK, **secret keys** for server-to-server calls, and **developer keys** for the CLI. Each prefix tells you exactly where it belongs. - [Checkout lifecycle](https://cimplify.dev/llms/docs/concepts/checkout-lifecycle.mdx): Every Cimplify checkout (embedded iframe, hosted Pay session, React ``, or headless API flow) passes through the same ordered set of states. Whether you observe them via `onStatusChange`, the `checkout_status` postMessage event, or the `on_status_change` callback on `processCheckout()`, the names and order are identical. - [Element events](https://cimplify.dev/llms/docs/concepts/element-events.mdx): The checkout iframe communicates with the parent page via window.postMessage. This is the raw protocol; SDK users usually consume higher-level controller events instead. - [Environments](https://cimplify.dev/llms/docs/concepts/environments.mdx): Cimplify runs in two modes. **Test mode** is either the in-process mock that ships with the SDK, or a sandbox business on the hosted APIs using `cpk_test_…` keys. **Live mode** is your real business, real catalogue, real money, gated by `cpk_live_…` keys. - [Errors](https://cimplify.dev/llms/docs/concepts/errors.mdx): SDK methods never throw. They return a `Result` whose error branch is a typed `CimplifyError` with a stable `code`, a human-readable `message`, an optional `retryable` hint, and structured `context`. - [Idempotency](https://cimplify.dev/llms/docs/concepts/idempotency.mdx): Every write method on the SDK accepts an optional `{ idempotencyKey }` as its second argument. Replays of the same key against the same body return the original response and never a duplicate side effect. - [Money](https://cimplify.dev/llms/docs/concepts/money.mdx): Every monetary value in the SDK is a `Money`: a branded string at runtime, a distinct type at compile time. Strings keep decimal precision intact across JSON, databases, and currency boundaries. - [Result](https://cimplify.dev/llms/docs/concepts/result.mdx): Every SDK method returns `Result` and never throws. You narrow on `.ok`, and TypeScript gives you either `value` or `error` on the other branch. - [Webhooks](https://cimplify.dev/llms/docs/concepts/webhooks.mdx): Cimplify pushes order, payment, and booking lifecycle events to your endpoint as JSON over HTTPS. Every delivery is HMAC-signed and replayed with exponential backoff if your server doesn't return a 2xx within 30 seconds. - [CheckoutElement](https://cimplify.dev/llms/docs/link/checkout-element.mdx): The unified checkout iframe. It renders contact capture, saved details, address, payment, provider authorization, and submit. Identity is handed off to Cimplify OAuth through the parent SDK. - [Payment links](https://cimplify.dev/llms/docs/pay/payment-links.mdx): A payment link is a short URL on `pay.cimplify.io/:token` that takes payment for an _already-existing_ order. Use these for invoicing flows: you bill someone offline, generate a token, drop the link into a WhatsApp / email / SMS, and the customer clicks through to settle. - [Checkout sessions](https://cimplify.dev/llms/docs/pay/sessions.mdx): A checkout session is a short-lived URL on `pay.cimplify.io` that hosts the full checkout for a specific cart. You create one server-side with your secret key, redirect the customer to the URL, and listen for the resulting webhook. - [Activity](https://cimplify.dev/llms/docs/sdk/activity.mdx): Lightweight session activity tracking: product views, category views, recommendations, and contextual messages. Calls are fire-and-forget where possible; failures never bubble into your UI. - [Assets](https://cimplify.dev/llms/docs/sdk/assets.mdx): Build CDN URLs for storefront brand assets, render them through `next/image`, and pass external image hosts (Cloudinary, Unsplash, merchant S3) through untouched. The SDK ships `assetUrl`, `isCimplifyAsset`, and `useImage`: pure functions; no network calls; SSR-safe. - [Sign in with Cimplify](https://cimplify.dev/llms/docs/sdk/auth.mdx): Add Cimplify sign-in to your storefront. One button, three route handlers, one React hook. Shoppers sign in via passkey or one-time code, then land back on your page signed in. - [Cart](https://cimplify.dev/llms/docs/sdk/cart.mdx): Session-bound cart. Add items with a flat payload, apply coupons, and read totals as branded ` Money` strings. The SDK returns `Result` on every method and never throws. - [Catalogue](https://cimplify.dev/llms/docs/sdk/catalogue.mdx): Browse products, variants, categories, collections, bundles, composites, deals, and price quotes. Read-only on the public client; safe to call from any environment. - [Checkout](https://cimplify.dev/llms/docs/sdk/checkout.mdx): Convert a cart into a paid order. The body is **flat**: fields like ` cart_id`, `customer`, `order_type`, and `payment_method` sit at the top level (not nested under any envelope). Production uses ` #[serde(flatten)]`; the SDK matches that shape exactly. - [Errors](https://cimplify.dev/llms/docs/sdk/errors.mdx): Every SDK method returns `Result`. Methods do not throw; instead you check `.ok` and branch on `error.code`. Wrap nothing in `try/catch`. - [FX](https://cimplify.dev/llms/docs/sdk/fx.mdx): Spot rates and locked quotes for cross-currency checkout. `checkout.process` will lock a quote for you automatically when `pay_currency` differs from the cart currency; call `fx.lockQuote` directly only when you need the rate ahead of time (e.g. to display "Pay in USD" before the customer commits). - [Link](https://cimplify.dev/llms/docs/sdk/link.mdx): client.link covers saved addresses, saved mobile money, link preferences, and sessions. Customer-scoped surface routed through the SDK's separate linkApiUrl transport, not the per-business storefront API. - [Performance & Optimization](https://cimplify.dev/llms/docs/sdk/optimization.mdx): How Cimplify storefronts cache and render fast, and the page-level knobs you control to keep them that way. - [Orders](https://cimplify.dev/llms/docs/sdk/orders.mdx): List, retrieve, and cancel orders. Anonymous orders carry a short-lived `bill_token` that the SDK persists for you, so guest order lookups Just Work after checkout. - [Places](https://cimplify.dev/llms/docs/sdk/places.mdx): Address autocomplete and place details for delivery checkout. Pass a ` sessionToken` through both calls to bill the autocomplete and the resolution as a single session. - [Rich product pages](https://cimplify.dev/llms/docs/sdk/product-pages.mdx): Render rich product description pages from sanitized HTML, compose multi-column layouts with the cimplify-* helpers, and generate bespoke pages per slug, including with AI. - [React hooks](https://cimplify.dev/llms/docs/sdk/react-hooks.mdx): 30+ hooks from `@cimplify/sdk/react`: typed, cached, and provider-driven. Each requires a `` ancestor. - [React SDK](https://cimplify.dev/llms/docs/sdk/react.mdx): 90+ components and 30+ hooks from `@cimplify/sdk/react`. Wrap your app in ``, drop in ``, ` `, ``, ``, or build from primitives with the data hooks. - [Revalidation](https://cimplify.dev/llms/docs/sdk/revalidation.mdx): Cache tags + revalidation helpers used to invalidate storefront Next.js ISR caches when the underlying data changes. - [Scheduling](https://cimplify.dev/llms/docs/sdk/scheduling.mdx): Variant-aware availability, slot picking, bookings, reschedules, and cancellations. As of ` 0.44.30`, slot fetches accept a `variant_id`; different service variants have different durations, prices, and slot availability. `duration_minutes` on ` getAvailableSlots` was removed; the server derives it from the variant. - [Server Components](https://cimplify.dev/llms/docs/sdk/server.mdx): `@cimplify/sdk/server` is a Node-only entry for the Next.js App Router. It ships three things: a request-memoized client factory, a typed cache-tag scheme, and Server Action revalidation helpers. - [Subscriptions](https://cimplify.dev/llms/docs/sdk/subscriptions.mdx): Read and manage the customer's recurring orders. Subscriptions are created during checkout when a billing plan is attached to a cart item; this surface lets you list them, pause / resume them, skip the next renewal, and cancel. - [Support](https://cimplify.dev/llms/docs/sdk/support.mdx): Customer-side chat conversation. The server resolves the active conversation from the widget identity on every request; there is no `conversation_id` to thread through. Open, send, and poll. - [Uploads](https://cimplify.dev/llms/docs/sdk/uploads.mdx): Three-step direct-to-storage upload: `init` hands you a presigned URL, ` PUT` the bytes, then `confirm` commits the upload. `upload(file)` is the one-call sugar that runs the whole sequence for you. - [Brand schema](https://cimplify.dev/llms/docs/templates/brand.mdx): Every storefront template ships a `lib/brand.ts` that owns every visible string. Pages, components, JSON-LD, sitemap, `llms.txt`, and metadata all read from `brand`, so a rebrand is one file. The shape is enforced at boot by `BrandSchema`, and at test time by `assertBrand(brand)`. - [Customizing a template](https://cimplify.dev/llms/docs/templates/customizing.mdx): The 95/5 split: ~95% of merchant changes are content (`lib/brand.ts`) and palette (`app/globals.css`). For the remaining 5% (restructured layouts, industry-specific sections, custom selectors), eject the SDK component or extend the brand schema. - [SEO & resource hints](https://cimplify.dev/llms/docs/templates/seo-and-resource-hints.mdx): Canonical URLs, robots meta, favicons, and preconnect hints: the four template-level head decisions that affect crawlability and LCP. - [Contracts](https://cimplify.dev/llms/docs/testing/contracts.mdx): The SDK and the backend agree on shapes by snapshotting both sides as JSON Schema and diffing on every CI run. The pipeline runs on every PR; drift breaks the build before it can reach a storefront. - [MSW transport](https://cimplify.dev/llms/docs/testing/msw.mdx): The same in-process Hono mock, exposed as MSW handlers. Use this transport when your tests need MSW's request interception: React Testing Library component tests, Playwright component runner, browser-mode vitest. One mock, two transports. - [Schemas](https://cimplify.dev/llms/docs/testing/schemas.mdx): Every shape the SDK, mock, and storefronts must agree on lives as a zod schema in `@cimplify/sdk/testing`. Schemas are registered with metadata, paired with typed `assertX` helpers, and exported as JSON Schema for downstream tooling. - [Suites](https://cimplify.dev/llms/docs/testing/suites.mdx): Three pre-baked vitest suites cover the common shape contracts. Templates wire them in three lines each: when a new case lands in the SDK, every storefront inherits it on `bun update @cimplify/sdk`. - [Test client](https://cimplify.dev/llms/docs/testing/test-client.mdx): `createTestClient({ seed })` spins up an in-process Hono mock and a typed SDK client wired to it via `fetch` injection: no port, no MSW, no `globalThis` mutation. Every call gets its own session token, so tests in the same module run in parallel safely. - [Add-ons](https://cimplify.dev/llms/docs/api-reference/catalogue/add-ons.mdx): Add-ons are modifier groups attached to a product (milk choice on a coffee, sauce on a bowl). Each group has options, a selection mode (single / multiple), and an optional `is_required` flag. Add-ons are surfaced inline on the product detail response and via a dedicated endpoint when you only need the modifier shape. - [Bundles](https://cimplify.dev/llms/docs/api-reference/catalogue/bundles.mdx): Bundles combine multiple products into a single purchasable unit at a fixed price: meal deals, gift sets, starter packs. Each `component` can require a specific quantity and optionally lock to a specific variant. - [Categories](https://cimplify.dev/llms/docs/api-reference/catalogue/categories.mdx): Categories group products into the navigation tree shoppers see in menus and storefront sidebars. They are flat at the API level; nesting is expressed via `parent_id`. - [Collections](https://cimplify.dev/llms/docs/api-reference/catalogue/collections.mdx): Collections are curated, often-time-bound groupings of products that don’t fit a single category, e.g. “Holiday gifts”, “Staff picks”, “Featured this week”. - [Composites](https://cimplify.dev/llms/docs/api-reference/catalogue/composites.mdx): Composites are build-your-own products: pizzas, salad bowls, PC builders. Each composite exposes one or more `component groups` with pricing and selection rules. Use `calculate-price` to preview the total before adding to cart. - [Products](https://cimplify.dev/llms/docs/api-reference/catalogue/products.mdx): Browse the active business’s catalogue. List endpoints accept rich filters; detail endpoints return a single product with its variants, add-ons, schedules, and deals. - [Variants](https://cimplify.dev/llms/docs/api-reference/catalogue/variants.mdx): Variants are options on a product (size, colour, duration, etc.). They are returned inline on the product detail endpoint, but there are also dedicated endpoints to list variants, look up a single variant by ID, and resolve a variant from a set of axis selections. - [Component catalog](https://cimplify.dev/llms/docs/sdk/react/components.mdx): 90+ React components ship in `@cimplify/sdk/react`. This page covers the page components you mount on routes, the cart drawer, and the most-used primitives. Every component is also [ejectable](/docs/cli/components) via ` cimplify add ` when you need full control.