Skip to main content
The Monigo JavaScript SDK (@monigo/sdk) is a thin, zero-dependency wrapper around the Monigo REST API. It follows a Stripe-style resource pattern — each API resource group is a typed service object hanging off the client. It ships as dual ESM and CommonJS bundles and works natively in Node.js (≥ 18), browsers, Cloudflare Workers, Bun, and Deno.

Installation

Or with other package managers:
Requires Node.js 18 or later for native fetch support. For Node.js 16, pass a fetch polyfill via the fetch option — see Client configuration below.

Quick start

Use a test-mode API key (mk_test_...) during development. Test events are isolated from live data and won’t trigger real charges.

Client configuration

Custom base URL

For self-hosted deployments or a local development server:

Polyfilling fetch (Node.js 16)

Testing

The fetch option makes the client fully testable without a real server:

Idempotency

Every POST, PUT, and PATCH request to the Monigo API must include an Idempotency-Key header. The SDK handles this automatically — crypto.randomUUID() is called for each mutating request. To supply your own key (recommended for retryable operations), pass idempotencyKey in the optional options argument:
For critical mutations (subscription creation, invoice finalization) pass a key derived from your own request ID. Retrying with the same key is safe — the server will return the original response without applying the operation twice.

Error handling

All methods return a Promise. A 4xx or 5xx response throws a MonigoAPIError with a typed status code, message, and optional field-level details.

Static type-narrowing guards

Events

The client.events service handles usage event ingestion and event replay.

Ingest events

The server deduplicates events by idempotency_key. A single call can include up to 1,000 events.
Always supply a stable idempotency_key so retries after a network error don’t double-count events. A good key is ${customer_id}_${event_type}_${request_id}.

Replay events

Replay reprocesses all events in a time window to correct rollups after an outage or metric definition change.

Customers

Set external_id to your own system’s user ID. This lets you look up customers by your existing identifier without storing Monigo’s UUID separately.

Metrics

A metric defines what gets counted and how raw event values are aggregated.

Plans

A plan combines billing period, currency, and one or more prices. Each price links a metric to a pricing model.

Pricing models

Plan types and billing periods

Subscriptions

A subscription links a customer to a plan and defines the current billing period.
A customer can hold at most one active subscription per plan type. A second active collection or payout subscription returns a 409 — catch it with MonigoAPIError.isConflict(err).

Payout accounts

Payout accounts are bank or mobile-money accounts scoped to a customer. All methods take customerId as the first argument.

Invoices

Invoices are generated from subscriptions and contain line items derived from the customer’s usage in the billing period.
All monetary amounts (subtotal, total, unit_price) are returned as decimal strings (e.g. "1500.00") to preserve precision across currencies.

Usage

Query aggregated usage rollups to see how much a customer has consumed in a period.

Portal tokens

Portal tokens grant an end-customer read-only access to their invoices, payout slips, subscriptions, and payout accounts in the Monigo hosted portal. The portal_url on the returned token is what you share with your customer — embed it in an email, redirect the browser, or open it inside an iframe.
Set expires_at (ISO 8601) for a time-limited link:

List tokens for a customer

customerId accepts either a Monigo UUID or the customer’s external_id.

Revoke a token

Revocation is immediate. Any customer holding the corresponding URL will receive a 401 on their next request.
Portal tokens are opaque 64-character hex strings stored in the database — not JWTs — so they can be instantly revoked without waiting for an expiry timestamp.

Wallets

Customer wallets hold prepaid balances. They are the foundation of Prepaid Billing and can also be used for any credit/debit workflow. See the full Wallet Management guide for details.

Wallet constants

All wallet amounts (balance, reserved_balance, ledger amount) are decimal strings to preserve precision.

Example programs

The SDK ships with seven runnable example programs under examples/: Run any example:
Each example reads MONIGO_API_KEY from the environment and accepts an optional MONIGO_BASE_URL to point at a local server.

Testing

The SDK ships 98 unit tests with zero external dependencies. Each test uses a mock fetch implementation injected via the fetch option:
To test against a local Monigo server: