Skip to content
Draai je bedrijfCommercial platform

Limieten ingebouwd

Stel limieten in per abonnement. Eén losgeslagen gebruiker jaagt je rekening niet omhoog.

Stel limieten in per abonnement. Eén losgeslagen gebruiker jaagt je rekening niet omhoog.

3
kinds of limits: per window, per billing period, at once
1
durable usage record behind every decision
0
limit decisions made in the browser

Productvoorbeeld

Bekijk het in werking

Dit is hetzelfde visuele component als in de ingelogde applicatie, met voorspelbare voorbeelddata.

Scenario
Voorbeeldscherm
Thema van voorbeeldoppervlak
Voorbeeldmodus

Within limits

Review included allowance, enforced limits, and remaining capacity.

Inerte voorbeelddata · geen netwerktoegang

Current usage

How much of the current plan this workspace has consumed in the open billing windows.

Credit balance

Prepaid credits available to this organization

0

Base subscription + usage

Included units
1,000
Overage units
0
Estimated usage charge
$0.00

Current-period overage only, before taxes and subscription fees. Your provider invoice is final.

Active projects

6 / 25

x
Server enforcedWindow ends Sep 1, 2026

19 remaining

25 Included in your plan

AI generations

684 / 2,500

x
Server enforcedWindow ends Sep 1, 2026

1,816 remaining

1,000 included before overage

Authenticated API requests (all organizations)

42 / 120

x
Enforced on integrated API routesWindow ends 9:31 AM

78 remaining

Voorbeeld gereed

Het probleem dat dit oplost

Zonder een gedeelde basis bouwt elk team deze randgevallen opnieuw — en anders.

The disabled button that wasn't

You gray out the button when a user hits their limit. Then someone calls the API directly, or keeps an old tab open, and blows right past it. A disabled button is not enforcement. The server deciding at write time is.

Paying customers locked out

A flaky network retries a request. A naive counter charges the quota twice. Now a paying customer is locked out of an allowance they never actually used, and they're right to be mad.

Nobody knows what Pro includes

Limits scattered across ad hoc if-statements drift apart until support asks what a plan actually allows and nobody can answer with confidence. One registry ends that.

Kernpunten

Waarom dit belangrijk is

One list of limits

Every limit lives in one typed file, so what each plan allows is written down in exactly one place.

Retries don't count twice

Each use carries a stable ID. A retried request gets the original answer back instead of charging quota again.

Locked by default

If the server can't tell what plan someone is on, the answer is no. Nothing slips through by accident.

Hoe het werkt

Het mechanisme van begin tot eind, zoals het in de repository is geïmplementeerd.

  1. 1

    Declare the limit once

    Each limit is one typed entry: what it counts, who it applies to, the time window, and what happens when it's hit.

  2. 2

    The server finds the plan

    It maps the subscription to a plan and its limits. A late payment gets a short grace window before access tightens.

  3. 3

    Usage is reserved inside the write

    The server locks, reads the usage ledger, and reserves the quota in the same transaction as your write. Races and retries settle safely.

  4. 4

    Clear errors, not mystery 500s

    A rate limit tells the caller exactly when to retry. A plan limit says so plainly, which is your upgrade prompt. The UI meters just explain the decision.

Technische garanties

Wat dit wel en niet belooft

Veiligheidsgrens

Achter de schermen houden autorisatie, tenantgrenzen en foutafhandeling één duidelijke eigenaar. Zo blijft de snelle ervaring voor gebruikers gekoppeld aan veilig herstel als het misgaat.

Implementatiebewijs

De grens hierboven is geen claim maar code. Deze bestanden dragen het contract:

  • src/registries/quotas.ts
  • src/server/commercial-access.ts
  • config/entitlements.ts
Vragen

Veelgestelde vragen

Bouw verder op Limieten ingebouwd

De documentatie beschrijft dezelfde contracten die deze pagina demonstreert.