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

# QuotaMint documentation

> Usage limits, credits, plans, and entitlements for SaaS products

QuotaMint is the runtime layer for products that need to answer one question reliably: **can this customer use this feature right now?**

It keeps customer plans, feature access, usage, and credits in one place. Your application remains responsible for billing and business logic; QuotaMint enforces the usage decision in your request path.

<CardGroup cols={2}>
  <Card title="Start with the quickstart" icon="rocket" href="/quickstart">
    Go from an empty project to your first idempotent credit consumption.
  </Card>

  <Card title="Understand the model" icon="diagram-project" href="/concepts">
    Learn how workspaces, projects, customers, plans, features, and environments fit together.
  </Card>

  <Card title="Read the API reference" icon="code" href="/api/overview">
    Check request fields, response shapes, denial reasons, and error codes.
  </Card>

  <Card title="Prepare for production" icon="shield-check" href="/production/security">
    Secure keys, configure retries, and add a denial path to your product.
  </Card>
</CardGroup>

## What QuotaMint owns

* Plan assignment and feature entitlements
* Atomic credit deduction and append-only credit history
* Usage events and usage reporting
* Idempotency for retries and concurrent requests
* Test and live API keys

## What QuotaMint does not own

QuotaMint is **not** a payment gateway, checkout system, tax service, or API gateway. Keep Stripe, Razorpay, Paddle, Lemon Squeezy, or your own billing system for payments. When a subscription changes, assign the resulting plan to the customer in the QuotaMint dashboard.

## Two doors into one system

Everything you configure and everything your code asks about lives in one place: the same customers, plans, features, credits, and usage records. You reach them through two doors.

**The dashboard is the door for people.** Your team sets up plans and features, creates customers and assigns plans, adds credits, mints and rotates API keys, and reads usage and audit history. If you can point at it on a screen, it happens here.

**The API is the door for your code.** Three endpoints, called at the moment of use:

* `/v1/check` — "could this customer use this feature right now?" (for UI hints; changes nothing)
* `/v1/consume` — "let them use it and charge the credits" (the decision your backend acts on)
* `/v1/events` — "record that this happened" (for usage that has no credit price)

The connection between the two doors is the point: what your team configures in the dashboard is exactly what the API enforces, per customer, per environment. Assign the `pro` plan in the dashboard, and the next `consume` for that customer costs what `pro` says it costs. No redeploy, no code change.

In practice, your product looks like this:

```text theme={null}
  Browser ──► your backend ──► QuotaMint API
                 (API key)         check / consume / events

  your team ──► QuotaMint dashboard
                 plans, features, customers, credits
```

Your frontend talks only to your own backend. Your backend calls the API with a project key that stays on the server — the browser never sees it. Your team works in the dashboard at their own pace; your code works at request speed.

That is the whole mental model: configure once in the dashboard, ask at the moment of use, act on the answer. The [quickstart](/quickstart) walks the shortest path through it; read [idempotency](/guides/idempotency) before sending production traffic.