@mercurjs/docs 2.2.0-canary.40

package/content/references/workflows/seller/update-seller-professional-details.mdx

@@ -0,0 +1,48 @@
+---
+title: "updateSellerProfessionalDetailsWorkflow"
+description: "Upsert a seller's professional (business) details."
+---
+
+Creates or updates the professional details record attached to a seller. Also run as a step by `createSellerAccountWorkflow` when professional details are provided at registration.
+
+## Usage
+
+```ts
+import { updateSellerProfessionalDetailsWorkflow } from "@mercurjs/core/workflows"
+
+const { result } = await updateSellerProfessionalDetailsWorkflow(container).run({
+  input: {
+    seller_id: "sel_123",
+    data: { corporate_name: "Acme GmbH", tax_id: "DE123456789" },
+  },
+})
+```
+
+## Input
+
+<ParamField body="seller_id" type="string" required>Id of the seller whose professional details are updated.</ParamField>
+<ParamField body="data" type="UpdateProfessionalDetailsDTO" required>
+  Fields to set; all optional.
+  <Expandable title="properties">
+    <ParamField body="corporate_name" type="string">Registered corporate name.</ParamField>
+    <ParamField body="registration_number" type="string">Company registration number.</ParamField>
+    <ParamField body="tax_id" type="string">Tax identifier.</ParamField>
+  </Expandable>
+</ParamField>
+<ParamField body="additional_data" type="object">Custom data passed through to the workflow hooks.</ParamField>
+
+## Result
+
+<ResponseField name="result" type="ProfessionalDetailsDTO">The updated professional details.</ResponseField>
+
+## Hooks
+
+- `professionalDetailsUpdated` — runs after the update with `{ professional_details, additional_data }`.
+
+```ts
+updateSellerProfessionalDetailsWorkflow.hooks.professionalDetailsUpdated(
+  async ({ professional_details }) => {
+    // e.g. re-run KYB checks
+  }
+)
+```

package/content/references/workflows/seller/update-sellers.mdx

@@ -0,0 +1,57 @@
+---
+title: "updateSellersWorkflow"
+description: "Update sellers matching a selector."
+---
+
+Updates every seller matching the selector with the given data. Triggered by `POST /admin/sellers/:id` and `POST /vendor/sellers/:id`. Emits `seller.updated` for each updated seller.
+
+## Usage
+
+```ts
+import { updateSellersWorkflow } from "@mercurjs/core/workflows"
+
+const { result } = await updateSellersWorkflow(container).run({
+  input: {
+    selector: { id: "sel_123" },
+    update: { name: "Acme Inc." },
+  },
+})
+```
+
+## Input
+
+<ParamField body="selector" type="object" required>Filter selecting the sellers to update, e.g. `{ id: "sel_123" }`.</ParamField>
+<ParamField body="update" type="UpdateSellerDTO" required>
+  Fields to update; all optional.
+  <Expandable title="properties">
+    <ParamField body="name" type="string">Display name.</ParamField>
+    <ParamField body="handle" type="string">URL handle.</ParamField>
+    <ParamField body="email" type="string">Contact email.</ParamField>
+    <ParamField body="description" type="string">Public description.</ParamField>
+    <ParamField body="logo" type="string">Logo URL.</ParamField>
+    <ParamField body="banner" type="string">Banner URL.</ParamField>
+    <ParamField body="website_url" type="string">Website URL.</ParamField>
+    <ParamField body="external_id" type="string">External system identifier.</ParamField>
+    <ParamField body="status" type="string">One of `open`, `pending_approval`, `suspended`, `terminated`.</ParamField>
+    <ParamField body="status_reason" type="string">Reason attached to the status.</ParamField>
+    <ParamField body="is_premium" type="boolean">Premium flag.</ParamField>
+    <ParamField body="closed_from" type="Date">Start of a store closure window.</ParamField>
+    <ParamField body="closed_to" type="Date">End of a store closure window.</ParamField>
+    <ParamField body="metadata" type="object">Custom key-value data.</ParamField>
+  </Expandable>
+</ParamField>
+<ParamField body="additional_data" type="object">Custom data passed through to the workflow hooks.</ParamField>
+
+## Result
+
+<ResponseField name="result" type="SellerDTO[]">The updated sellers.</ResponseField>
+
+## Hooks
+
+- `sellersUpdated` — runs after the update with `{ sellers, additional_data }`.
+
+```ts
+updateSellersWorkflow.hooks.sellersUpdated(async ({ sellers }) => {
+  // sync updated sellers elsewhere
+})
+```

package/content/resources/ai/llms.mdx

@@ -0,0 +1,74 @@
+---
+title: "LLMs"
+description: "Feed Mercur documentation directly to LLMs for accurate, context-aware assistance."
+---
+
+# LLMs
+
+Mercur documentation is optimized for Large Language Models using the [llms.txt standard](https://llmstxt.org). This gives AI tools a structured map of all documentation — so they can answer technical questions accurately instead of guessing.
+
+Think of it like a sitemap, but for AI: a machine-readable file that describes what documentation exists, how it's organized, and where to find specific topics.
+
+<Note>
+  This page is for **chat assistants and hosted tools** (Claude, ChatGPT). If you're using a coding agent *inside* a Mercur project, prefer the version-matched docs bundled in `node_modules/@mercurjs/docs/` — see [Building with AI](/rc/resources/ai/overview).
+</Note>
+
+---
+
+## Available files
+
+### llms.txt
+
+A structured index of all Mercur documentation pages with descriptions and links.
+
+```
+https://docs.mercurjs.com/llms.txt
+```
+
+Use this when your AI tool supports llms.txt natively or when you want to give it an overview of what's available without sending the full content.
+
+### llms-full.txt
+
+The entire Mercur documentation compiled into a single plain-text file.
+
+```
+https://docs.mercurjs.com/llms-full.txt
+```
+
+Use this when you want to give an LLM the complete context in one shot — ideal for complex questions that span multiple topics.
+
+---
+
+## How to use
+
+<Tabs>
+  <Tab title="Claude Projects">
+    1. Open [Claude](https://claude.ai) and create a new Project
+    2. In project knowledge, add a URL: `https://docs.mercurjs.com/llms-full.txt`
+    3. Claude now has full Mercur documentation context in every conversation within that project
+  </Tab>
+  <Tab title="ChatGPT">
+    1. Download `https://docs.mercurjs.com/llms-full.txt`
+    2. Upload it as a file in your conversation or attach it to a Custom GPT's knowledge base
+  </Tab>
+  <Tab title="AI IDE (paste)">
+    For any AI coding tool that accepts context:
+    1. Fetch the file: `curl -o mercur-docs.txt https://docs.mercurjs.com/llms-full.txt`
+    2. Attach it to your conversation or project context
+  </Tab>
+</Tabs>
+
+<Tip>
+  Both files are auto-generated and always reflect the latest documentation. No maintenance required.
+</Tip>
+
+---
+
+## When to use llms.txt vs MCP
+
+| Approach | Best for |
+|----------|----------|
+| **llms.txt / llms-full.txt** | One-time context loading, tools without MCP support, offline use |
+| **[MCP Server](/rc/resources/ai/mcp)** | Live search, always up-to-date results, integrated AI environments |
+
+For the best experience, use the [MCP server](/rc/resources/ai/mcp) if your tool supports it. Fall back to llms.txt when MCP isn't available.

package/content/resources/ai/mcp.mdx

@@ -0,0 +1,152 @@
+---
+title: "MCP Server"
+description: "Connect your AI environment to Mercur documentation via Model Context Protocol."
+---
+
+# MCP Server
+
+Mercur exposes a [Model Context Protocol](https://modelcontextprotocol.io) (MCP) server that lets AI tools **search Mercur documentation directly**. Instead of relying on training data that may be outdated, your AI assistant queries the actual docs in real time.
+
+```
+https://docs.mercurjs.com/mcp
+```
+
+---
+
+## Available tool
+
+### SearchMercurJsDocumentation
+
+Searches across all Mercur documentation and returns:
+
+- Relevant excerpts matching your query
+- Page titles for context
+- Direct links to documentation pages
+
+Use it when you need to look up API references, understand how a module works, find CLI commands, or retrieve examples during development.
+
+---
+
+## Connect to your AI environment
+
+<Tabs>
+  <Tab title="Cursor">
+    <Steps>
+      <Step title="Open MCP settings">
+        1. Press <kbd>Cmd</kbd> + <kbd>Shift</kbd> + <kbd>P</kbd>
+        2. Search for **Open MCP settings**
+        3. Select **Add custom MCP**
+      </Step>
+      <Step title="Configure the server">
+        Add the following to your `mcp.json`:
+
+        ```json
+        {
+          "mcpServers": {
+            "mercur": {
+              "url": "https://docs.mercurjs.com/mcp"
+            }
+          }
+        }
+        ```
+      </Step>
+      <Step title="Use it">
+        Restart Cursor and ask: **"Search Mercur docs for how to add a block"**
+      </Step>
+    </Steps>
+
+    See [Cursor MCP docs](https://docs.cursor.com/en/context/mcp) for more.
+  </Tab>
+  <Tab title="VS Code">
+    <Steps>
+      <Step title="Create MCP config">
+        Create a file at `.vscode/mcp.json` in your project root.
+      </Step>
+      <Step title="Configure the server">
+        ```json
+        {
+          "servers": {
+            "mercur": {
+              "type": "http",
+              "url": "https://docs.mercurjs.com/mcp"
+            }
+          }
+        }
+        ```
+      </Step>
+      <Step title="Use it">
+        Open the Copilot Chat panel and ask: **"List available MCP servers."**
+      </Step>
+    </Steps>
+
+    See [VS Code MCP docs](https://code.visualstudio.com/docs/copilot/chat/mcp-servers) for more.
+  </Tab>
+  <Tab title="Windsurf">
+    <Steps>
+      <Step title="Open MCP config">
+        1. Press <kbd>Cmd</kbd> + <kbd>Shift</kbd> + <kbd>P</kbd>
+        2. Search for **Open Windsurf MCP Configuration**
+      </Step>
+      <Step title="Configure the server">
+        ```json
+        {
+          "mcpServers": {
+            "mercur": {
+              "serverUrl": "https://docs.mercurjs.com/mcp"
+            }
+          }
+        }
+        ```
+      </Step>
+      <Step title="Use it">
+        Open Cascade and ask: **"Search Mercur docs for seller setup"**
+      </Step>
+    </Steps>
+  </Tab>
+  <Tab title="Claude">
+    <Steps>
+      <Step title="Add the MCP server">
+        1. Go to Claude → Settings → **Connectors**
+        2. Select **Add custom connector**
+        3. Enter:
+           - **Name**: Mercur
+           - **URL**: `https://docs.mercurjs.com/mcp`
+        4. Save
+      </Step>
+      <Step title="Use it">
+        In chat, click the **attachments (+)** button and select your Mercur MCP connector.
+      </Step>
+    </Steps>
+
+    See [Claude connector docs](https://modelcontextprotocol.io/docs/tutorials/use-remote-mcp-server) for more.
+  </Tab>
+  <Tab title="Claude Code">
+    <Steps>
+      <Step title="Install the MCP server">
+        ```bash
+        claude mcp add --transport http mercur https://docs.mercurjs.com/mcp
+        ```
+      </Step>
+      <Step title="Verify installation">
+        ```bash
+        claude mcp list
+        ```
+      </Step>
+      <Step title="Use it">
+        Claude Code can now query Mercur documentation directly during any conversation.
+      </Step>
+    </Steps>
+
+    See [Claude Code MCP docs](https://docs.anthropic.com/en/docs/claude-code/mcp) for more.
+  </Tab>
+</Tabs>
+
+---
+
+## Choosing an approach
+
+| Approach | Best for |
+|----------|----------|
+| **[Bundled docs](/rc/resources/ai/overview)** | Coding agents inside a project — version-matched, offline, no setup |
+| **MCP Server** | Live search from your editor, always the latest published docs |
+| **[llms.txt](/rc/resources/ai/llms)** | Feeding full context to a chat assistant (Claude, ChatGPT) |

package/content/resources/ai/overview.mdx

@@ -0,0 +1,97 @@
+---
+title: "Building with AI"
+description: "Mercur ships version-matched docs inside your project so AI coding agents build from accurate APIs instead of stale training data."
+---
+
+Mercur is built so AI coding agents work from **accurate, version-matched documentation** instead of their training data — which is almost always out of date for a fast-moving framework. The docs ship *inside your project's dependencies*, and your project tells agents to read them before writing any code.
+
+<Info>
+  **Why agents do well here.** Every extension surface an agent touches has a machine-checkable contract: routes generate the [typed client](/rc/tools/api-client) (wrong calls fail to compile), pages follow [file conventions](/rc/resources/customization/extending-panels) the SDK validates at build time, and blocks are diffable source. An agent doesn't need to guess whether its change works — the toolchain tells it.
+</Info>
+
+## How it works
+
+When you install a Mercur project, the documentation is bundled as a dependency at `node_modules/@mercurjs/docs/`. It mirrors the structure of this site:
+
+```txt
+node_modules/@mercurjs/docs/
+├── llms.txt              # index: every page with a one-line description
+└── content/
+    ├── learn/            # concepts — sellers, products, offers, commissions…
+    ├── resources/        # tutorials, integrations, deployment, this guide
+    ├── tools/            # CLI, API client, dashboard SDK
+    ├── references/       # module, HTTP API, and configuration reference
+    └── user-guide/       # admin and vendor panel usage
+```
+
+Because the docs travel with the package, an agent always has documentation that **matches your installed version** — no network request, no external lookup, and no drift between what the agent reads and what your code actually runs.
+
+## Set up your project
+
+### New projects
+
+Projects created with `bunx @mercurjs/cli@rc create` are ready out of the box. The template ships:
+
+- `@mercurjs/docs` as a dependency, so the docs land in `node_modules` on install
+- an `AGENTS.md` and a `CLAUDE.md` at the project root that tell agents to read the bundled docs first
+
+Most AI coding agents — Claude Code, Cursor, GitHub Copilot, and others — read `AGENTS.md` automatically when they start a session. There is nothing else to configure.
+
+### Existing projects
+
+Add the docs dependency:
+
+```bash
+bun add @mercurjs/docs
+```
+
+Then create an `AGENTS.md` at the project root with a single, focused instruction:
+
+```md AGENTS.md
+# Mercur: read the docs before coding
+
+Before any non-trivial change, read the bundled documentation — it is
+version-matched to this project's installed packages, and far more accurate
+than training data.
+
+1. Read the index: `node_modules/@mercurjs/docs/llms.txt`
+2. Open the pages it points to under `node_modules/@mercurjs/docs/content/`
+
+Don't guess at an API, data model, or file convention the docs already describe.
+```
+
+[Claude Code](https://docs.anthropic.com/en/docs/claude-code) reads `CLAUDE.md`; point it at the same instructions instead of duplicating them:
+
+```md CLAUDE.md
+@AGENTS.md
+```
+
+## What the agent reads
+
+The workflow is deliberately simple: **index first, then the page.** An agent reads `llms.txt` to see what exists, then opens the one or two `content/` pages relevant to the task before implementing. The bundled docs cover the full domain model (sellers, products, offers, attributes, commissions, payouts, order groups), the CLI, the typed API client, the dashboard SDK, module references, and how-to guides — so the agent looks up the correct contract rather than inventing one.
+
+## Verify its work
+
+Mercur gives an agent a fast, machine-checkable way to know whether a change is correct — the equivalent of a grading loop it can run itself:
+
+| Check | What it proves |
+|-------|----------------|
+| `bun run build` | Types resolve and the generated client matches the routes |
+| `bun run lint` | Code conforms to the project's rules |
+| Integration tests (`packages/api`) | Backend behavior still holds |
+| `bunx @mercurjs/cli@rc diff` | Local blocks vs. the registry — what changed and what drifted |
+
+Because these are objective, an agent can define what "done" looks like, run the checks, read the output, and iterate until they pass — instead of stopping at "looks plausible."
+
+## Beyond bundled docs
+
+The bundled docs are for agents working *inside your project*. For chat assistants and hosted tools, Mercur also publishes its docs online:
+
+<CardGroup cols={2}>
+  <Card title="llms.txt" href="/rc/resources/ai/llms">
+    Feed the full documentation to Claude, ChatGPT, or any LLM.
+  </Card>
+  <Card title="MCP server" href="/rc/resources/ai/mcp">
+    Let your editor search the docs live via Model Context Protocol.
+  </Card>
+</CardGroup>

package/content/resources/customization/custom-fields.mdx

@@ -0,0 +1,182 @@
+---
+title: "Custom Fields"
+description: "Extend any Medusa entity with additional fields without modifying core code."
+---
+
+Custom Fields let you attach extra data to any existing Medusa entity — products, customers, orders, and more — through configuration alone. No migrations to write, no models to define. The module handles table creation and schema updates automatically when you run `db:migrate`.
+
+<Info>
+  **Where this sits in the stack.** Custom Fields is a Mercur module (`@mercurjs/core/modules/custom-fields`) layered on top of Medusa's standard module-link system — it generates the side table, the link, and the schema for you. It's the lightest way to add data to an entity.
+</Info>
+
+## When to use Custom Fields
+
+<Tip>
+  **Use Custom Fields when** the data is a plain property of an existing entity — it belongs to exactly one record, has no lifecycle of its own, and you mostly read it alongside its parent. Typical cases:
+
+  - A `brand`, `warranty_months`, or `is_featured` flag on a product
+  - A `company_name` or loyalty `tier` on a customer
+  - An internal `source` or `priority` tag on an order
+
+  You get a typed column, a default value, and queryability through `query.graph` — for the cost of one config entry and a `db:migrate`.
+</Tip>
+
+<Warning>
+  **Build a custom Medusa module instead when** the data outgrows "extra columns":
+
+  - It has its **own lifecycle** — created, updated, and deleted independently of the parent (e.g. reviews, support tickets)
+  - It has **relations** to more than one entity, or many records per parent
+  - It carries **business logic** — validation rules, state transitions, workflows
+  - You need **its own API routes** and permissions around it
+
+  Custom Fields is strictly one row per parent entity. Forcing a one-to-many or stateful concept into a JSON field works until it doesn't — model it as a module (or check whether a [block](/rc/learn/blocks) already ships it).
+</Warning>
+
+## How it works
+
+The Custom Fields module creates a separate table for each entity you extend (e.g. `product_custom_fields`). Each table is linked back to the original entity via a foreign key with a unique constraint, ensuring a one-to-one relationship. The module automatically registers these links so you can query custom fields through Medusa's standard remote query.
+
+## Set up custom fields
+
+<Steps>
+  <Step title="Define your fields in medusa-config.ts">
+    Register the Custom Fields module and describe your fields in the `customFields` option:
+
+    ```ts medusa-config.ts
+    import { Modules } from "@medusajs/framework/utils";
+
+    module.exports = defineConfig({
+      // ...
+      modules: [
+        {
+          resolve: "@mercurjs/core/modules/custom-fields",
+          options: {
+            customFields: {
+              Product: {
+                brand: { type: "string", nullable: true },
+                is_featured: { type: "boolean", defaultValue: false },
+                weight: { type: "float", nullable: true },
+              },
+              Customer: {
+                company_name: { type: "string", nullable: true },
+                tier: {
+                  type: "enum",
+                  enum: ["bronze", "silver", "gold"],
+                  defaultValue: "bronze",
+                },
+              },
+            },
+          },
+        },
+      ],
+    });
+    ```
+
+    <Warning>
+      The key in `customFields` (e.g. `Product`, `Customer`) must match the entity name as registered in Medusa's joiner configuration — a mismatched name fails at link resolution, not at config load, so double-check spelling and casing.
+    </Warning>
+  </Step>
+  <Step title="Run migrations">
+    ```bash
+    bunx medusa db:migrate
+    ```
+
+    The module generates and applies the schema for each side table automatically.
+  </Step>
+  <Step title="Query the fields">
+    Custom fields are automatically linked to their parent entity. Retrieve them with Medusa's remote query:
+
+    ```ts
+    const products = await query.graph({
+      entity: "product",
+      fields: ["id", "title", "custom_fields.*"],
+    });
+    ```
+  </Step>
+</Steps>
+
+## Supported field types
+
+| Type       | Description                                               |
+| ---------- | --------------------------------------------------------- |
+| `string`   | Short text                                                |
+| `text`     | Long text                                                 |
+| `integer`  | Whole number                                              |
+| `float`    | Decimal number                                            |
+| `boolean`  | True/false                                                |
+| `date`     | Date only                                                 |
+| `time`     | Time only                                                 |
+| `datetime` | Date and time                                             |
+| `json`     | JSON object                                               |
+| `array`    | Array of values                                           |
+| `enum`     | One of a predefined set of values (requires `enum` array) |
+
+### Field options
+
+| Option         | Type       | Default | Description                                      |
+| -------------- | ---------- | ------- | ------------------------------------------------ |
+| `nullable`     | `boolean`  | `true`  | Whether the field can be null                    |
+| `defaultValue` | `any`      | `null`  | Default value for the field                      |
+| `enum`         | `string[]` | —       | Required for `enum` type. List of allowed values |
+
+## Using the service directly
+
+The Custom Fields module exposes a service with `upsert`, `delete`, and `list` methods. You can use these in your own workflows and API routes:
+
+```ts
+import { MercurModules } from "@mercurjs/types";
+
+// In a step or API route
+const customFieldsService = container.resolve(MercurModules.CUSTOM_FIELDS);
+
+// Create or update custom fields for a product
+await customFieldsService.upsert("product", {
+  id: "prod_123",
+  brand: "Acme",
+  is_featured: true,
+});
+
+// Delete custom fields by record ID
+await customFieldsService.delete("product", ["cf_456"]);
+```
+
+The `upsert` method accepts either a single object or an array. If a record already exists for the given entity ID, it updates it; otherwise, it creates a new one.
+
+## Workflow steps
+
+The module ships with two workflow steps you can compose into your own workflows:
+
+```ts
+import {
+  upsertCustomFieldsStep,
+  deleteCustomFieldsStep,
+} from "@mercurjs/core/workflows";
+```
+
+- **`upsertCustomFieldsStep`** — Takes `{ alias, data }` where `alias` is the entity name (e.g. `"product"`) and `data` contains the entity ID and field values.
+- **`deleteCustomFieldsStep`** — Takes `{ alias, ids }` to soft-delete custom field records by their IDs.
+
+## FAQ
+
+<AccordionGroup>
+  <Accordion title="Can I add or change fields after the first migration?">
+    Yes — edit the `customFields` config and run `db:migrate` again; the module updates the side table's schema. Removing a field from config stops exposing it; treat destructive column changes with the same care as any schema migration.
+  </Accordion>
+  <Accordion title="How do vendors or admins edit these values from the panels?">
+    Through your own UI: add a page or re-compose an existing one ([extending panels](/rc/resources/customization/extending-panels)) and call an API route that uses the service's `upsert` — or compose `upsertCustomFieldsStep` into a workflow behind a [custom route](/rc/resources/tutorials/custom-api-route).
+  </Accordion>
+  <Accordion title="Can one entity have multiple custom-field records?">
+    No — the side table has a unique constraint on the parent ID, enforcing one-to-one. If you need many records per parent, that's a custom module, not custom fields.
+  </Accordion>
+</AccordionGroup>
+
+## Next steps
+
+<CardGroup cols={2}>
+  <Card title="Add a custom API route" href="/rc/resources/tutorials/custom-api-route">
+    Expose your custom fields through a typed endpoint.
+  </Card>
+  <Card title="Extend a workflow" href="/rc/resources/customization/extend-a-workflow">
+    Write custom fields from inside existing business flows.
+  </Card>
+</CardGroup>

package/content/resources/customization/extend-a-workflow.mdx

@@ -0,0 +1,39 @@
+---
+title: "Extend a workflow"
+description: "Inject custom logic into an existing Mercur workflow through hooks — without rewriting it."
+---
+
+<Note>
+  This guide is being written. The outline below is the intended structure.
+</Note>
+
+<Info>
+  **Workflows are Medusa's extension model — Mercur keeps it.** Unlike the panels (where Mercur ships [its own customization framework](/rc/resources/customization/extending-panels)), backend logic follows Medusa conventions unchanged: Mercur's workflows expose hooks you inject steps into, with the same compensation/rollback semantics as any Medusa workflow. Skills learned in plain Medusa transfer here one-to-one.
+</Info>
+
+## Why hooks
+
+Extend behavior without forking or rewriting the workflow.
+
+<Steps>
+  <Step title="Pick the target hook">
+    The `completeCartWithSplitOrdersWorkflow` and where its hooks sit.
+  </Step>
+  <Step title="Inject a step">
+    The shape of a hook and how to register your step.
+  </Step>
+  <Step title="Handle compensation and rollback">
+    How your step participates in automatic rollback on failure.
+  </Step>
+</Steps>
+
+## Verify
+
+Confirm the injected behavior runs and rolls back correctly.
+
+## Next steps
+
+<CardGroup cols={2}>
+  <Card title="Add a custom API route" href="/rc/resources/tutorials/custom-api-route" />
+  <Card title="Custom fields" href="/rc/resources/customization/custom-fields" />
+</CardGroup>