Identity · Metering · Billing
Sign them in. Meter what they use. Bill them for it.
Base316 is identity and usage-based billing in one control plane. A single call answers whether an account may do something and who pays for it, so entitlements, metering and invoices cannot drift apart.
- Free includes production
- No card to start
- SDKs in 7 languages
- externalId
- "acct_northwind"
- feature
- "ai.tokens"
- externalUserId
- "usr_ada"
- permission
- "reports.export"
- requested
- 2,000
Remaining this period
237,600
- Used this period812,400
- Plan allowance1,000,000
- Prepaid credits50,000
- Role that passedadmin · direct
Illustrative figures. The fields are the real response of one access check: the decision, the usage behind it and the role that granted it.
Production on Free
Live keys from day one, not a sandbox.
You're the merchant
Payments settle to your Stripe account.
No double billing
Every usage event carries a required key.
Exact money
Rated in decimal arithmetic, rounded once.
7 official SDKs
No third-party dependencies in any.
Why one platform
Two systems that usually drift apart
Identity and billing are normally separate products stitched together with webhooks, and they disagree the moment one of them is late. Here they share one model — and one call answers both halves of the question.
The usual stack
Three records, joined by webhooks
- A cancelled plan keeps unlocking features until a webhook lands.
- A new user exists in auth before billing knows the account.
- Usage is counted in your code, then counted again for the invoice.
Base316
One record, read three ways
One account · one plan version · one usage ledger
Identity
Users, tenants, roles and sessions
Entitlement
What the plan grants, measured live
Billing
Invoices from the same usage
- The check that unlocks a feature reads the plan that bills for it.
- Usage is metered once, and the invoice is computed from it.
- A permission and an allowance are answered in the same call.
Product tour
From sign-in to settled revenue, in one dashboard
Six stages of one request, each with the screen that runs it. Captured from the running product with demo data.
01 · Identity
Our sign-in page, or your own
Point your users at a hosted page Base316 brands and maintains, and they come back signed in. Passwords, passkeys, a magic link or their employer's identity provider — the same page, the same session. Or keep your own screens and drive the same flows through the SDK: the session, the MFA factors and the SSO routing are identical either way.
Platform
What you would otherwise buy from four vendors
Identity, billing, tenancy and prepaid usage, sharing one model of your accounts.
01 · Identity
The identity provider, not a wrapper around one
One issuer per environment, deliberately shaped like Cognito, so an application already pointed at a user pool can be repointed without changing its code.
- OIDC and SAML 2.0. Authorization code with PKCE, refresh rotation, JWKS and userinfo. SAML is SP-initiated only, because an unsolicited assertion has no request to bind to.
- Enterprise SSO by email domain. A work address routes to the employer's provider instead of a password check, and just-in-time provisioning creates the account on first sign-in.
- Your own fields, typed. Declare what you need to know about your users once. The SDK hands it back typed, generated from a real environment rather than hand-written.
02 · Billing
Usage-based billing that settles correctly
The fee in advance after any trial, usage in arrears, proration on a plan change, and a credit note for the part nobody used. Money is computed in decimal and rounded once.
- One call decides entitlement. It answers whether an account may use a feature, measured against its limit plus any credits, and says why when it refuses rather than returning false.
- You stay the merchant of record. Stripe Connect direct charges settle against your own account, so you keep your Stripe dashboard and chargebacks land on your balance, not ours.
- Quotes, terms and offline payment. Most B2B revenue never touches a card. Quote it, send it for approval, then record the wire against the invoice — including a part payment.
03 · Tenants and roles
Your customers' users, tenants and roles
An end user belongs to an organization through a membership, and the membership carries a role. Roles grant from a permission catalog your own application defines, so what a person may do is a question with an answer rather than a convention.
- One call for both questions. `access.check` takes a feature or a permission. The same call answers “is this account entitled” and “may this user do it”, so authorisation and billing can never disagree about the same request.
- Roles you define, not ours. Owner, admin and member are a starting point. A role is a key and a list of permissions, and the permission keys are strings your code already checks for.
- A tenant is not a customer. The organization your user signs into and the account you invoice are separate records, linked where they line up. One company can be several tenants, or several companies one bill.
04 · Prepaid usage
Sell usage before it is used
Not every product bills a month in arrears. Sell a pack of tokens, a block of minutes or a top-up balance, and let the same meters draw it down — so the thing a customer buys and the thing they consume are one number rather than two that have to be reconciled.
- Credits against a meter. A grant is an amount of a metered feature, with an expiry. Usage draws it down before it becomes billable, so a customer is never charged for what they had already bought.
- A wallet that pays invoices. A prepaid balance per account, applied to an invoice before any card is attempted, with a threshold that says when it is running low.
- Refused before the spend. Ask for the amount you are about to use. A request that would exceed the allowance is refused before the work happens, rather than surfacing as an overage on a bill nobody expected.
For developers
One call, and it tells you why
A bare false sends somebody to the dashboard to guess. Every refusal carries the reason, the limit, what has been used and what is left — so the error your customer sees can say something useful. The same surface is a REST API, seven client libraries, a CLI and an MCP server.
- 400
- API operations in the published OpenAPI spec
- 7
- official SDKs, from TypeScript to C#
- 0
- third-party dependencies in any of them
const decision = await base316.access.check({
externalId: "acct_globex",
feature: "api.calls",
requested: 1,
});
// Refused, and it says why — not a bare false.
{
allowed: false,
reason: "USAGE_LIMIT_EXCEEDED",
usage: {
used: 1_000_000,
limit: 1_000_000,
credits: 0,
remaining: 0,
},
}How it works
Four calls, and you are billing
Install the client, sign them in, record what happens, and ask before you do the work. Plans, proration, invoices, dunning and the reports all follow from those without anything else in your code changing.
01
Install and point it at your key
One client for the whole surface: auth, access, events, customers and subscriptions. The key's own prefix says which environment it is for, so a sandbox key cannot touch production data by accident.
install.ts# Node, or any of six others pnpm add @base316/sdk import { Base316 } from "@base316/sdk"; const base316 = new Base316(); // Reads BASE316_SECRET_KEY from the environment.02
Sign them in, your way or ours
Send users to a page Base316 hosts and brands, and exchange the code that comes back for a session. Or keep your own screens and call the same flows directly — the session, the MFA factors and the SSO routing are identical either way.
signin.ts// Our hosted page — send them here, they come back with a code. const session = await base316.auth.exchangeCode({ code }); // Or your own screens, against the same flows. await base316.auth.signUp({ email, password }); await base316.auth.session(token);03
Record what your customers use
Fire an event where the work happens. The idempotency key is required rather than optional, because a retry after a network timeout must not bill the same work twice and only you know what “the same work” means.
usage.tsawait base316.events.record({ event: "api.call", externalId: "acct_globex", payload: { count: 1 }, idempotencyKey: requestId, }); // Required, not optional: a retry after a timeout // must not bill the same work twice.04
Ask before you do the work
The same call takes a feature or a permission, so it answers “does this account have allowance left” and “may this user do it”. A refusal carries the reason, the limit and what is left — enough to tell somebody something useful instead of “no”.
gate.tsconst { allowed, reason, usage } = await base316.access.check({ externalId: "acct_globex", feature: "api.calls", }); if (!allowed) { return tooManyRequests(reason); } // The same call, asking about a person in that account. await base316.access.check({ externalId: "acct_globex", userId, permission: "billing.manage", });
Security
Tenancy comes from the key, never the request
Every request's workspace, project and environment are read from the API key that made it. An id in a URL or a body is never evidence of permission.
Isolation tested the way an attacker would
Cross-tenant id substitution is in the test suite. A resource you don't own and one that doesn't exist get the same answer.
Secrets we can't leak
Secret keys are stored only as a SHA-256 digest and shown once. Provider credentials you give us are encrypted with AES-256-GCM.
Sandbox can't reach production
Every project has a Sandbox and a Production environment, and the key's prefix is re-checked against the environment on every request.
Hosted pages with no JavaScript
Sign-in pages are server-rendered under a strict content policy, with PKCE, CSRF protection and single-use 60-second codes.
Pricing
Start free. Upgrade when the limits bite.
Free carries production access, so the limits are what move you up rather than a locked door. Every plan bills the workspace, not the person who signed up.
Free
Ship on it. It is production, not a sandbox.
- 1 project, with production access
- 1,000 end users · 100 customers
- 100k metered events a month
- Multi-factor authentication included
- 7-day event retention
Pro
For a team selling a product and invoicing for it.
14 days free trial
- 5 projects · 5 seats
- 25,000 end users · 5,000 customers
- 5M metered events a month
- Invoicing, payment collection and dunning
- Custom branding and impersonation
- 90-day event retention
Scale
For products carrying real production traffic.
- Unlimited projects and API keys · 20 seats
- 250,000 end users · unlimited customers
- 50M metered events a month
- Custom authentication domain
- 400-day event retention
Enterprise
Limits, security review and terms set by contract.
- Negotiated limits rather than a table
- Enterprise SSO, SAML 2.0 and your own issuer
- Dedicated support and an agreed response time
- Invoicing on your terms, security review, DPA
Questions
Questions teams ask before they switch
Straight answers about billing, identity and moving over.
Get started
Ship the product, not the billing engine
Free is a real tier with production access, not a sandbox. Start there and upgrade when the limits actually bite.
- Production access on Free
- No card to start
- Import presets for Chargebee, Lago, Stripe and Clerk