Nine systems, one platform.
Each system is a complete piece of a backend with its own endpoints, dashboard and allowance. Use one or all of them. They share an identity, an audit log and an account, so the ones you add later already know about the ones you have.
- IdentityPasswordless sign-in, sessions, organizations and roles, shared across every app you run.Sign-in, accounts and teams
- BillingSubscriptions, one-off payments and invoicing, with entitlements your code checks in a single call.Plans, checkout and entitlements
- MeteringRecord what each customer uses, sell it as credits or limits, and see what every model call cost you.Usage, credits and model cost
- DataStore your app's data without designing tables first, and query it with filters that never become raw SQL.Records, queries, search and files
- MessagingTransactional email from your own domain, web push, an in-app inbox and live channels.Email, push, inbox and realtime
- AutomationBackground jobs with retries, schedules, and signed webhooks to and from your systems.Jobs, schedules and webhooks
- ObserveProduct analytics, errors, traces and alerts for every app, on one dashboard.Analytics, errors and alerts
- FlagsSwitch features on by user, plan or percentage, and turn them off again without a deploy.Feature flags and rollouts
- ModelsCall any major model through one endpoint, with fallbacks, allow-lists and a spend cap for every customer.One gateway to every model
Put together a backend.
Choose systems to see the command that adds them and what they do together.
Add them to an app
$ npx dianthan add identity billing observe
What they do together
- identity+billingCheckout already knows who is paying, and entitlements arrive with the session.
One plan includes every system for every app in the account, so adding one later costs nothing extra.
What the pairs do.
Because the systems share one identity and one event stream, you don't write the code that connects them.
- Identity + Billing
Checkout already knows who is paying, and entitlements arrive with the session.
- Billing + Metering
Plans carry quotas, and usage counts against them as it happens.
- Metering + Observe
Model spend sits next to activity, so you can see a costly account before the invoice does.
- Identity + Flags
Target a flag by role, organization or the plan someone is on.
- Billing + Flags
Roll a feature out to one plan before you put it on the pricing page.
- Messaging + Automation
Email on a schedule or after a delay, with retries and a delivery log.
- Data + Automation
Record changes trigger signed webhooks to your other systems.
- Identity + Messaging
Message a person, not an address, and respect the preferences they set.
- Data + Identity
Records can belong to a user or a team and are filtered to them automatically.
- Observe + Flags
Compare error rates and events between the people with a flag on and those without.
- Metering + Messaging
Tell a customer they're running low on credits before they run out.
- Billing + Messaging
Receipts, failed-payment notices and trial reminders go out without extra code.
- Models + Billing
Each customer's model cost is set against what they paid, so you can see who you lose money on.
- Models + Identity
Every model call is attributed to a signed-in person, so caps and costs are per customer.
- Models + Metering
Usage you meter and model spend sit on the same customer, so a plan's limits can cover both.
- Models + Observe
Model latency, errors and spend sit beside the rest of your product's activity.