Customer Credits is in Experimental preview.
How transactions work
Every time you add or remove credits, a transaction is created. Transactions are permanent — you always have a complete history of what happened and why.Credit
Add credits to an account
Debit
Remove credits from an account
Reverse
Undo a previous transaction
Credit — add credits
Use this when a customer earns credits, buys a credit pack, or receives a reward.Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
amount | string | ✅ | How many credits to add. String to support large numbers |
reference | string | ✅ | Link this to your system — an order ID, campaign name, anything |
idempotency_key | string | ✅ | Prevents double-processing on retries |
Debit — remove credits
Use this when a customer spends credits, uses a feature, or redeems a reward."side": "debit" in the entry.
The API prevents negative balances — if a debit would bring the balance below zero, it returns an
insufficient_balance error. Check the balance first if you want to show your users a friendly message.Reverse — undo a transaction
Made a mistake? Order cancelled? Reverse a transaction to undo it. The original transaction stays in the history — a new opposite transaction is created so you always have a complete paper trail."reversal_of": "cct_3mNpK8rW2xY" linking back to the original.
Viewing history
See every credit and debit on an account, newest first.side—"credit"(added) or"debit"(removed)amount— how many creditstransaction_id— links back to the transaction (which has thereferenceandidempotency_key)
What is an idempotency_key?
An idempotency_key is a unique string you include with every credit or debit request. It’s your safety net against accidental duplicates.
Imagine your app credits a customer 500 points for an order. The request goes through, but your app doesn’t get the response back (network hiccup, timeout, server restart). Without protection, retrying would give the customer 1,000 points instead of 500.
The idempotency_key prevents this. When you retry with the same key, Creem recognizes it’s the same request and returns the original result — no double-crediting.
How it works
| Scenario | Result |
|---|---|
| First request | Processes normally |
| Retry with same key + same body | Returns original result, X-Idempotent-Replay: true header |
| Same key but different body | 409 Conflict error |
Next steps
Accounts
Create, freeze, and manage accounts.
Recipes
Step-by-step guides for common patterns.
API Reference
Full endpoint schemas.
Introduction
Back to overview.