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

> ## Agent Instructions
> Taberna is a crypto payments API. Amounts are priced in fiat (USD or EUR) and paid in crypto.
> Fiat amounts are ALWAYS decimal strings ("9.99"), never numbers. Crypto amounts are integer strings in the asset's smallest unit.
> Authenticate merchant endpoints with `Authorization: Bearer tbrn_live_...`. Every key is bound to one store and carries an explicit scope set, so never pass a store id to a /v1 endpoint.
> A 401 means the credential is bad; a 403 means the key lacks a scope. Never retry or re-authenticate on a 403 — surface it as a configuration error.
> The /v1/checkouts endpoints are deliberately unauthenticated and run in the buyer's browser. Never send an API key to a browser.
> Verify webhook signatures over the RAW request body before parsing JSON, and treat delivery as at-least-once: handlers must be idempotent.
> Never grant value based on a browser redirect to successUrl. Fulfil on a signature-verified webhook, or on a server-side read of GET /v1/orders/{id} or GET /v1/invoices/{id}.
> There is no test mode: every payment method is a live chain moving real funds.
> A merchant can run an entire shop with no code: the dashboard creates products and invoices, and every store can host a storefront at {slug}.taberna.io with its own theme, sections, branding and optional custom domain. Never assume the reader has an API integration.
> Taberna issues no refunds and performs no KYC. A refund is something the merchant sends from their own payout wallet, off-platform.

# Build with the API

> What the Taberna API does, how to choose between orders and invoices, and where to start.

The Taberna API lets your server charge a customer in crypto, priced in fiat. You create
a charge, redirect the buyer to a hosted checkout page, and a signed webhook tells you
when the money landed on-chain.

You do not build coin selection, exchange-rate display, deposit addresses, QR codes or
confirmation progress. Those live on Taberna's hosted pages.

## How it works

1. Your server creates an **order** or an **invoice** and gets back a hosted checkout
   link.
2. You redirect the buyer to that link. They pick a token, pay a locked quote, and watch
   it confirm.
3. Taberna POSTs a signed `order.completed` or `invoice.paid` webhook to your endpoint.
   You fulfil there.

## Orders or invoices

<Tabs>
  <Tab title="Orders (catalogue)">
    Best when you sell a **fixed set of things** at fixed prices — plans, tiers,
    licences, downloads.

    Create the products once (in the dashboard), then reference them by id:

    ```json theme={"dark"}
    { "items": [{ "productId": "0197f8a0-…", "quantity": 2 }] }
    ```

    Taberna computes the total, reserves any finite delivery stock for the order's
    lifetime, and attaches the delivery to the completed order.
  </Tab>

  <Tab title="Invoices (dynamic amounts)">
    Best when the **amount is decided per request** — account credits, usage
    top-ups, consulting fees, one-off bills.

    No product setup at all; you compose the line items in the create call:

    ```json theme={"dark"}
    { "items": [{ "name": "124 credits", "quantity": 1, "unitAmount": "124" }] }
    ```

    Invoices also carry `metadata`, a sequential `number`, a customer name and memo,
    and can be emailed to the customer.
  </Tab>
</Tabs>

## Dashboard versus API

The split is deliberate: anything that **configures** the store is a human action in
the dashboard; anything that **transacts** is available to your server.

| In the dashboard (logged-in human)             | Via API key (your server)                                        |
| ---------------------------------------------- | ---------------------------------------------------------------- |
| Create the store, set its name and image       | Read the store — `GET /v1/store`                                 |
| Enable payment methods, set payout wallets     | —                                                                |
| Create and edit products, configure delivery   | Read products, append delivery stock — `/v1/products`            |
| Create and edit invoice templates              | List templates — `GET /v1/invoice-templates`                     |
| Mint and revoke API keys                       | —                                                                |
| Set the webhook URL, rotate the signing secret | List and resend deliveries — `/v1/webhook-deliveries`            |
| Browse and manage orders and invoices          | Create, read, expire, void, email — `/v1/orders`, `/v1/invoices` |

<Info>
  There is no API-key route to create products, stores, invoice templates or API
  keys, and a merchant can run an entire shop without ever writing code — see
  [Sell without code](/guides/sell-without-code). If you are integrating against a
  store someone else set up, read [What Taberna does not
  do](/guides/what-taberna-does-not-do) before you design around a capability.
</Info>

## Where keys come from

API keys are minted in the dashboard by a store owner, admin or manager, are bound to
one store, and carry an explicit scope set. There is no implicit full-access key and no test key
prefix. See [Authentication](/authentication).

## Start here

<CardGroup cols={3}>
  <Card title="Quickstart" icon="rocket" href="/quickstart">
    Mint a key, create an order, redirect, fulfil on the webhook.
  </Card>

  <Card title="Webhooks" icon="tower-broadcast" href="/webhooks">
    The ten events, payload shapes, and signature verification.
  </Card>

  <Card title="API Reference" icon="terminal" href="/api-reference">
    Every endpoint and every field, generated from the running service.
  </Card>
</CardGroup>