> ## Documentation Index
> Fetch the complete documentation index at: https://docs.joinmarkt.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> How Join Markt HTTP APIs are organized, authenticated, and versioned.

## Welcome

Join Markt exposes HTTP JSON APIs from your deployment origin. Unlike platforms that publish a single OAuth2 admin API, Join Markt splits traffic by **trust boundary**:

| Surface                | Audience               | Auth                                          |
| ---------------------- | ---------------------- | --------------------------------------------- |
| Public catalog & embed | Merchant sites, themes | None (product ownership enforced server-side) |
| Checkout lifecycle     | Buyers / storefront JS | Rate limits + checkout tokens                 |
| Payment webhooks       | Gateways               | Signature verification                        |
| Vendor dashboard       | Sellers / staff        | Session cookie + permissions                  |
| Customer portal        | End customers          | Customer session                              |
| Platform admin         | Operators              | Admin session                                 |

## Base URL

```bash theme={null}
https://YOUR_APP_ORIGIN
```

Examples use absolute paths from that origin. Storefront HTML is also served on:

```bash theme={null}
https://{subdomain}.YOUR_APP_ORIGIN
```

Checkout invoices live at `/checkout/{orderId}` and are **excluded** from subdomain rewrite rules — always link to the app origin for checkout, not `/store/{subdomain}/checkout/...`.

## What is documented here

This reference prioritizes **integrator-facing** routes:

* Embed checkout
* Checkout start / client gate
* Public storefront catalog
* Coupon validation
* Order delivery / keys
* Page-view tracking
* Incoming payment webhooks (overview)

Dashboard CRUD for products, tickets, team, and analytics exists under `/api/*` with session auth. Those handlers are thin wrappers over `lib/domains/*` and follow the same permission matrix as the UI (`viewOrders`, `manageCoupons`, `manageSettings`, …). Documented endpoint pages are added where external developers commonly integrate; the rest follow the same patterns as the open-sourced route handlers.

## Conventions

* Validate input with Zod at the route / domain boundary.
* Prefer `{ error: string }` on failure for public routes (some order errors spread extra payload keys).
* Rate limits use `rateLimit(identifier, { maxRequests, windowMs })` keyed by client IP / forwarded identity.
* CSRF tokens apply when `requireSession` / `requireAdmin` runs — not on pure public checkout routes.

## Next

1. [Quick Start](/api/quick-start) — first successful public call
2. [Authentication](/api/authentication) — sessions vs public vs webhooks
3. [Rate limiting](/api/rate-limiting) — budgets that will page you at 2am
4. Pick an endpoint group: [Catalog](/api/get-storefront), [Checkout](/api/checkout-start), [Embed](/api/embed-checkout)
