Developer docs
Neruba Billing Engine gives builders a direct route into the first working loop, then opens deeper reference only when the project actually needs it.
Understand the model before you read endpoint details.
Use quickstart and examples to wire the first loop.
Bring in readiness, support, and deployment posture.
Use trust and architecture when scrutiny increases.
Choose the shortest path to the answer the team needs right now
Use docs as a routing page, not a long read. Start with quickstart for a working stack, open examples for copyable requests, and bring in architecture or trust only when the project reaches that depth.
- You need to decide which page solves the current implementation question fastest.
- A reviewer needs the right technical artifact without reading the full marketing surface first.
- You want one shared shelf for quickstart, request flows, operations, architecture, and trust.
- 1Open quickstart for the first working environment and readiness loop.
- 2Jump to examples when the team needs real request shapes and replay-safe writes.
- 3Use implementation, operations, architecture, or trust only when the rollout question gets sharper.
Find the fastest path to a working integration
Use quickstart for first validation, examples for request shape, operations for hardening, and architecture or trust when more reviewers join the conversation.
Use overview and concepts to understand the billing shape before writing code.
Use examples and quickstart to make the first request loop work end to end.
Bring architecture, trust, and security in when more stakeholders enter the room.
Use implementation and operations material when rollout questions become real.
A reference shelf teams can share
Route the team to the right next page: orient on the model, copy the first request flow, confirm readiness, and open architecture or trust only when the project reaches that level of scrutiny.
Confirm the project boundary and the key scopes before any ingest traffic is live.
Pair every usage or charge write with stable IDs so retries stay safe.
Check balances, ledger entries, or billing overview so the write has visible financial consequences.
Keep a copyable request trail the next engineer or operator can understand quickly.
Commercial model
Use this reference section to understand how pricing, balances, billing runs, and outputs fit together before you wire endpoints or rollout flows.
- Projects / tenants and project-scoped access
- Subscriptions, usage, prepaid credits, and hybrid pricing
- Deterministic billing runs and recomputation
- Wallets, balances, and ledger-backed adjustments
- Billing and reconciliation outputs
API and integration surface
Use this section when the team needs the actual integration surface: auth, scoped keys, ingest, wallet reads, payments, and operator-facing endpoints.
- Usage ingestion endpoints with idempotency keys
- Project and API-key management primitives
- Wallet, ledger, and payment reads
- Checkout and Stripe webhook entry points
- Admin and support-oriented endpoints
5-minute quickstart
The fastest path to a working local demo, first-run checks, and a `/health/ready` confirmation before deeper rollout work starts.
Implementation guide
The rollout model: event shape, launch sequencing, deployment posture, and how to manage cutover risk before billing touches production money.
Capabilities map
A grounded view of projects, ingest, billing runs, ledger state, payments, admin actions, and operator tooling.
Copyable request flows
The first integration loop most teams need: auth, project creation, project API keys, usage ingest, and billing reads.
Architecture map
Domain modules, ingress boundaries, and why the codebase separates transport, compute, and financial state the way it does.
A practical checklist before launch gets close
- • Map the pricing model: subscription, usage, credits, or hybrid
- • Define your event schema, idempotency keys, and replay expectations before sending live traffic
- • Choose your MySQL/MariaDB path and confirm how migrations will run in each environment
- • Walk through auth, project setup, project API keys, usage ingest, and billing reads before you broaden the surface area
- • Use readiness checks and smoke paths to prove the stack is healthy before deeper validation
- • Decide Swagger and OpenAPI posture by environment instead of leaving docs exposure implicit
- • Plan ledger, billing, reconciliation, and support workflows before cutover
Buyer onboarding, Docker and local paths, doctor checks, and the first `/health/ready` loop.
Concrete request flows for `/ingest/usage`, `/ingest/usage/batch`, and `/ingest/charge`, including idempotency handling.
Scheduler locking, recovery sweeps, docs posture, deployment modes, and support workflows.
Use the architecture map and migration review checklist when teams need to understand seams, cutover, and rollback risk.
A lightweight asset for sharing internally while the team aligns on rollout approach, stakeholders, and next questions.
Get working faster and open deeper material only when it earns its place
Neruba Billing Engine gives teams the shortest route into the first working loop, the reference pages they need as the system broadens, and the material that helps security, operations, and architecture join at the right time.
Ingress boundaries should stay explicit before domain logic fans out.
Balances, credits, and financial state need one durable story the team can inspect.
Conflict-safe helpers, dedupe, and replay boundaries need to be visible early.
The architecture should leave room for operators to explain and recover, not just process requests.