# 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<url>.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<T, CimplifyError>` 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 exposes a single REST surface at `/api/v1/*`. All requests are JSON. Most reads are public storefront calls keyed by `pk_`; writes that touch a customer require an active session cookie obtained from `/auth/verify-otp`.
- [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 endpoint and emit the same [Element events](/docs/concepts/element-events).
- [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 the shopper-facing layer of Cimplify: a saved-payment-and-address vault, an OTP identity, and a small set of embeddable iframe Elements that let merchants pull that identity into any storefront. It's hosted at `link.cimplify.io` and ships as the `@cimplify/link` package.
- [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.
- [Auth](https://cimplify.dev/llms/docs/api-reference/auth.mdx): Customer-facing OTP login. Requesting an OTP delivers a 4–6 digit code over SMS or email; verifying it issues a session cookie that subsequent calls (cart, checkout, orders) recognise as the same customer.
- [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](https://cimplify.dev/llms/docs/api-reference/link.mdx): /v1/link/*: customer-scoped Link API. Hosted on api.cimplify.io, separate from the per-business storefront API.
- [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.
- [Subscriptions](https://cimplify.dev/llms/docs/api-reference/subscriptions.mdx): Read and manage the authenticated customer’s subscriptions. All endpoints require an active customer session (cookie set by `/auth/verify-otp`).
- [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 (`sk_…`) on `X-API-Key`.
- [Appearance API](https://cimplify.dev/llms/docs/checkout/appearance.mdx): Every Cimplify Element iframe (`AuthElement`, `CheckoutElement`, `AccountElement`, the hosted Pay page) accepts an `appearance` object that controls theme, accent color, font, and corner radius. The same shape works across all integration tiers.
- [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/<sessionId>` (auth, address, payment method, compliance). You get a webhook (or success-URL redirect) when payment lands.
- [Controlled Elements (React)](https://cimplify.dev/llms/docs/checkout/elements.mdx): React wrappers around the Cimplify Element iframes. Drop a component into your tree, pass a few props, and you have a working checkout. The iframe still does all the rendering; you just orchestrate it with React.
- [Embedded checkout iframe](https://cimplify.dev/llms/docs/checkout/embedded.mdx): The same checkout UI as the hosted Pay page, but you mount it as an iframe on your own domain. No SDK needed; just an `<iframe>` and a few postMessage listeners. Use this when you want to stay on your domain but don't need React (or want to mount inside Vue, Svelte, plain HTML, a webview, etc).
- [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 Elements](https://cimplify.dev/llms/docs/checkout/vanilla.mdx): The framework-agnostic checkout surface. Use this from Vue, Svelte, plain HTML, or anywhere else React isn't the right tool. The same controller backs the React wrappers; they're just convenience around `CimplifyElements`.
- [Component registry](https://cimplify.dev/llms/docs/cli/components.mdx): 67 ejectable components ship in the registry. `cimplify list` shows every component; `cimplify add <name>` 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.
- [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.
- [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, or controlled React Element) 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): Cimplify Elements communicate with the parent page via `window.postMessage`. Below is the full event union sent _from_ the iframe, defined as `IframeToParentMessage` in `@cimplify/sdk`. The parent-side controller in the SDK already validates and dispatches these for you; this page is for when you want to wire them up directly.
- [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 at `api.cimplify.io` using `pk_test_…` keys. **Live mode** is your real business, real catalogue, real money, gated by `pk_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<T, CimplifyError>` 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.
- [AccountElement](https://cimplify.dev/llms/docs/link/account-element.mdx): An embeddable, chrome-less version of the Link dashboard. Drop it on any page where the customer is already signed in to Cimplify Link and they can manage their saved addresses, payment methods, sessions, orders, and subscriptions without leaving your domain.
- [AuthElement](https://cimplify.dev/llms/docs/link/auth-element.mdx): A single-line OTP sign-in component. Customer types an email or phone number, presses submit, types the 6-digit code, and the Element emits an `authenticated` event with a Link session token. Use it standalone (e.g. on a login page) or alongside other Elements (the parent controller broadcasts the token to them automatically).
- [CheckoutElement](https://cimplify.dev/llms/docs/link/checkout-element.mdx): The full unified checkout iframe. Auth, address, payment method, and submit all live in one frame. This is the iframe behind `<CimplifyCheckout>` and the hosted Pay page, sharing the same code at `packages/link/src/pages/elements/checkout/`.
- [Link dashboard](https://cimplify.dev/llms/docs/link/dashboard.mdx): The shopper-facing UX at `link.cimplify.io`. Customers visit it directly to manage their saved details across every Cimplify-powered storefront. This page is a tour of what shoppers see; these screens are _not_ embeddable on their own (use [AccountElement](/docs/link/account-element) for that).
- [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.
- [Authentication](https://cimplify.dev/llms/docs/sdk/auth.mdx): OTP-based sign-in over phone or email. No passwords. The SDK manages the session token end-to-end; a successful `verifyOtp` call wires the token into every subsequent request.
- [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<T>` 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<T, CimplifyError>`. 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.
- [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.
- [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 `<CimplifyProvider>` ancestor.
- [React SDK](https://cimplify.dev/llms/docs/sdk/react.mdx): 90+ components and 30+ hooks from `@cimplify/sdk/react`. Wrap your app in `<CimplifyProvider>`, drop in `<CataloguePage>`, ` <ProductPage>`, `<CartPage>`, `<CheckoutPage>`, or build from primitives with the data hooks.
- [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.
- [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 <name>` when you need full control.