QuotaMint

QuotaMint is a backend service for managing customer plans, feature access, usage limits, and credits in SaaS applications. It answers one question from your backend — can this user do this, and what does it cost? — and then writes the ledger. The product is built for developers creating SaaS, AI applications, API products, or any software that needs plan-based access, credits, or usage limits. Instead of building and maintaining credit tables, usage counters, monthly resets, plan checks, feature access rules, usage limits, usage history, retry protection, and upgrade or downgrade handling, teams can call one API. QuotaMint keeps product access logic in one place instead of scattered across a backend. Every usage-based SaaS eventually ends up maintaining the same infrastructure, and QuotaMint turns that into a small API. A usage counter is easy, but maintaining everything around it is not. Without QuotaMint, teams often deal with plan logic scattered across code, custom counters, custom credit resets, difficult retry handling, difficult usage history, and billing-provider-specific logic. The familiar problem is that product rules leak into product code and become hard to change. QuotaMint is designed to keep product rules out of your product code by centralizing plan configuration, consistent feature access, credit tracking, a usage audit trail, and billing-provider independence behind one consume() API. The core interaction is a single consume() call. Before your backend does the work, it sends a POST request to /v1/consume with a customer ID you already use, a feature name that was priced when you set up the plan, and an idempotency key. QuotaMint checks the customer's plan, feature access, credit cost, and remaining balance, then answers allow or deny. Denied calls are normal answers, not errors, so your application can return a 402 or show an upgrade prompt instead of charging anything. This is plain HTTPS with no SDK and no client library, and the REST API works unchanged from TypeScript, Go, Python, Ruby, and any other backend language that can make an HTTPS POST. Retries are a first-class concern. If you pass an idempotency key with consume(), and the same request is retried, QuotaMint returns the original result instead of consuming again. This means that if a network died, a worker crashed, or a queue redelivered the job, you can send the same key again and get the first answer back while the customer is charged exactly once. In the example shown, the first request deducts 10 credits and a retry adds 0 additional credits. This is idempotent consumption by design, and it protects usage-based products from double-charging when jobs are retried. Plans and feature costs are configured once and reused. You create plans such as Starter with 500 credits per month and Pro with 2,000 credits per month, then define feature costs — for example, generate_text costs 1 credit, generate_image costs 10 credits, and generate_video costs 50 credits. Different features can cost different amounts, and plans can enable or disable features. Plans can also have different monthly credit amounts and define recurring credit allocations such as monthly credits. Every consume() call checks the plan, the feature, and the balance before answering whether the action is allowed or denied. QuotaMint is built to work alongside an existing billing stack rather than replace it. It does not replace Stripe, Paddle, Razorpay, Lemon Squeezy, or your billing system, and it does not process cards or collect payments. Your application tells QuotaMint which plan a customer has, and QuotaMint handles everything after that: credits, usage, and runtime access decisions. When a subscription changes — upgrade, downgrade, or cancel — you set the customer's plan in the QuotaMint dashboard, and balances and history carry over untouched. Payment stays with your billing provider while runtime access decisions stay with QuotaMint, and native billing integrations are planned later. Visibility is a core part of the product. You can configure access and inspect every credit from the dashboard, so plans, feature costs, balances, and usage history stay visible without digging through application logs. A customer view can show an active Pro plan, credits remaining, usage this month by feature, feature access toggles, and recent usage entries. QuotaMint keeps usage history so you can see when, where, and which feature consumed credits, and every consumption creates an immutable usage record with identifiers and timestamps. This gives teams a usage audit trail rather than relying only on application logs. The overall approach is to define the rules once and call one API. You create your plans, define feature costs, and call consume(); each call checks the plan, the feature, and the balance, then answers allow or deny. QuotaMint is not an API gateway and does not sit in front of your API, so you do not need to proxy all of your traffic through it. Your application calls QuotaMint from the backend, and it is one HTTPS POST sized to run inside your request path. It focuses on application-level usage and feature-access logic, and it is not intended to replace a full API gateway. The benefits follow from this boundary. Teams get one consume() API, central plan configuration, consistent feature access, credit tracking, a usage audit trail, and billing-provider independence. Product rules stay out of product code, so plan changes and feature access changes do not require rewriting logic scattered across the backend. Retry handling becomes safe through idempotency, and usage history becomes available without custom reporting. Because QuotaMint is payment-provider independent, teams can change or keep their billing provider without changing how runtime access decisions are made. QuotaMint is designed for usage-based products of several kinds. AI SaaS teams can charge credits for images, text, video, tokens, documents, or agent runs. API products can track API usage, set usage limits, and control feature access. B2B SaaS teams can enable features based on plans without hard-coding plan logic everywhere. Credit-based apps can manage monthly credits, top-ups, rollovers, and consumption. It can also track arbitrary usage units including tokens, images, API calls, documents, storage, minutes, or custom credits, and it can be used without credits when a product only needs feature access or usage limits. Pricing and capacity are sold per workspace, and every plan runs the same checks, consumption, credits, idempotency, and Test/Live isolation. The Free plan is $0 per workspace per month with 5,000 events each month, 1 project, 60 runtime requests per minute, 3 days of usage history, 2 Test and 2 Live API keys per project, and 1 team member. Pro is $29 per workspace per month with 2,000,000 events each month, 5 projects, 600 runtime requests per minute, 30 days of usage history, 10 Test and 10 Live API keys per project, and 5 team members. Scale is $79 per workspace per month with 10,000,000 events each month, no project cap, 3,000 runtime requests per minute, 90 days of usage history, unlimited Test and Live API keys, and 20 team members. Usage resets on the first day of each UTC month. All plans include customer plans, feature entitlements, atomic credit deduction, idempotency, API authentication, monthly grants, manual credit changes, and separate Test and Live data. A launch offer code, LAUNCH50, gives 50% off the first paid billing period. QuotaMint's primary value proposition is simple: stop rebuilding credits and usage limits. Keep your existing billing provider, define plans and feature costs once, and let one consume() API answer whether a customer can use a feature and what it costs. That keeps runtime access decisions, credit tracking, and usage history in one place while your product code focuses on the product itself.