Marketplaces
A ledger per seller, with holds at checkout and balanced settlement across seller, platform and tax accounts.
For platforms
If you resell, host or integrate on behalf of other businesses, give each of them their own ledger: their own accounts, their own records, their own keys. They cannot see each other, and they cannot see you.
How it works
1
A partner credential administers your clients and nothing else: it cannot move money, so a leaked partner key cannot post a transaction.
2
One request creates an isolated ledger for a client: their own accounts, their own journal, their own keys. Create a production ledger and a sandbox; the kind can never be changed later.
3
Mint a key for the client with the role they need — read, post, or administer their own accounts. The secret is shown once.
4
See when each key was last used, suspend a client and restore them, revoke a key instantly. Suspension takes effect on their very next request and changes no history.
POST /v1/sub-tenants
Authorization: Bearer rak_… (your partner key)
Content-Type: application/json
{ "name": "Acme Retail", "kind": "production", "contact_email": "ops@acme.example" }
201 Created
{
"tenant_id": "799c3e0b-7ce2-4faa-868f-77b256c208e7",
"name": "Acme Retail",
"status": "active",
"kind": "production",
"created_at": "2026-08-23T00:35:11.857680+00:00"
}
# You never supply a parent: it is taken from your credential,
# so there is nothing to get wrong and nothing to forge.The full flow, including issuing and revoking keys and suspension, is in the sub-tenants guide.
Keys and roles
| Role | What it can do | Typical use |
|---|---|---|
| Reader | Read balances, statements and transactions. | Reporting, dashboards, finance reviews. |
| Poster | Everything a reader can, plus post transactions and settle holds. | The normal application key. |
| Admin | Everything a poster can, plus define asset types and open accounts. | Set-up and configuration. |
| Partner | Create, suspend, restore and issue keys for your own clients. Cannot post. | Platforms, agencies, resellers. |
A leaked partner key cannot move money, and a leaked posting key cannot create tenants. Keys are issued by RODMENA’s authorisation service; the ledger itself holds nothing capable of minting a credential it would accept.
Who runs ledgers for others
A ledger per seller, with holds at checkout and balanced settlement across seller, platform and tax accounts.
Give each customer their own wallet or credit balance without building a ledger into your product.
Programme-level books with a separate ledger for every client, isolated by the database rather than by convention.
Points and stored value issued on behalf of many brands, each with its own liability that can be derived at any moment.
Keep books for several businesses under one account, with the guarantee that none of them can see another.
Questions
No. A partner key administers a client; it cannot read or write their ledger, and there is no endpoint that crosses that line. Administering a client and being able to see their money are different powers, on purpose.
You do: a client’s API calls count against your plan. Your plan covers the clients you serve, and they do not need plans of their own.
Every key of theirs is refused on the very next request until you restore them. Nothing is deleted and nothing is altered; suspension stops access, it does not touch history.
No. The model is deliberately one level deep, so the questions “whose plan pays for this call” and “who may administer this” always have one answer.
Because the journal is permanent. A sandbox lets an integrator make mistakes somewhere that is not production, and its kind can never be changed to production afterwards.
Tell us what you keep books of and for whom; we will provision a partner tenant and walk you through creating your first client.