Billing

Enscrive billing has two parts that work together:

1. A subscription — your tier (Solo, Pro, Enterprise), purchased and managed from the portal’s Billing page.
2. A prepaid wallet — metered usage (embedding tokens) debits a wallet you top up with credit bundles.

Everything is priced from a single versioned rate card, served publicly at GET /v1/ratecard, and every wallet debit records the rate-card version it was priced under — so any bill can be replayed and checked.

All amounts in the API are integer micro-dollars (*_micros): 1,000,000 micros = $1.00.

Subscription tiers

Solo and Pro subscriptions are purchased through a hosted Lemon Squeezy checkout launched from the portal’s Billing page, which also mints a self-service customer-portal link for managing an existing subscription. The exact subscription numbers — including the Pro seat minimum and Enterprise instance pricing — are published on the rate card.

The prepaid wallet

Metered usage is debited from a prepaid wallet rather than invoiced after the fact. You top it up from the portal’s Billing page with credit bundles of $10, $25, $50, or $100, again via hosted checkout.

Read your balance

GET /v1/wallet/balance

{
  "balance_micros": 12340000,
  "balance_display": "$12.34",
  "low_balance": false
}

low_balance is true below $1.00. Wallet reads are GETs, which the billing gate treats as non-billable — a tenant whose balance has gone negative can still read it to diagnose.

Read your debit history

GET /v1/wallet/debits?since=2026-06-01T00:00:00Z&limit=50

Returns debit transactions newest-first: amount_micros (negative), balance_after_micros, transaction_type, reference_id, metering_event_id, description, created_at. Only debit rows are returned — funding, refund, and adjustment rows are excluded, so what you see is exactly the charges you are verifying.

What is metered

Embedding tokens, priced per million tokens by model bucket:

• ingress — tokens embedded when you ingest documents,
• egress — tokens embedded for your queries at search time.

Each embedding model belongs to a bucket (small or large); the bucket’s rates and its full model list are on the rate card. Bring-your-own-key (BYOK) usage is billed at separate, lower platform rates since the provider bills you directly for the embedding itself.

Two cost behaviors worth knowing:

• Fingerprint dedup is free in the strongest sense — re-ingesting unchanged content is detected and skipped: no provider call, no debit. See Ingest.
• Batch-set cost accounting — for batch ingests, chunk_count and total_tokens on the batch-set are the authoritative usage figures for that ingest.

Storage is metered today and the rate card publishes a disk-rent rate, but storage debits are not yet applied to wallets — only embedding-token usage debits today.

Soft-stop floors

When your wallet balance crosses your tier’s soft-stop floor, new billable requests are refused with 402 Payment Required until you top up:

The negative floors are a contractual grace window: Pro and Enterprise work keeps running modestly past zero rather than failing mid-task. Two gates enforce the floor:

• the per-request gate — refuses new billable requests at the edge (non-billable reads, like wallet balance, still work);
• the in-job gate — long-running background work (ingest jobs, eval campaigns) re-checks the balance at batch boundaries and aborts cleanly if the wallet crosses the floor mid-job.

The 402 body names your balance, your tier, and the floor, so the fix is never a mystery.

The rate card

GET /v1/ratecard
GET /v1/ratecard?at=2026-05-23T00:00:00Z

Public — no API key required. Returns the rate card active now (or at the ?at= instant): version, effective_from/effective_to, per-bucket token rates with model lists, BYOK rates, storage rates, subscription tiers, soft-stop floors per tier, hard-stop floors (the drain ceiling the debit pipeline enforces past the soft stop), and the per-tier revision retention windows.

Historical lookups with ?at= return the card that was active at that instant; a time before the first card was applied is a 404.

Determinism

Every wallet debit is computed against the rate card that was active when the metered usage occurred, and the ledger row records that rate_card_version. Combined with the historical ?at= lookup, this makes bills replayable: for any debit you can fetch the exact card it was priced under and recompute the charge from the recorded token counts.

Cross-references

• Ingest — fingerprint dedup and what launches billable embedding work.
• Batch-sets — authoritative per-ingest usage accounting.
• Revisions — retention windows carried on the rate card.
• Errors — HTTP-level errors, including 402.