Marketplaces
A seller gets their own ledger. Funds are held at checkout, and settlement across seller, platform and tax accounts is one balanced transaction.
For platforms
If you resell, host or integrate on behalf of other businesses, give each of them their own ledger. They get their own accounts, their own records and their own keys. They cannot see one another, and they cannot see you.
How it works
1
A partner credential administers your clients and cannot move money. A leaked partner key cannot post a transaction.
2
One request creates an isolated ledger for a client. They get their own accounts, their own journal and their own keys. Create a production ledger and a sandbox. The kind cannot be changed afterwards.
3
Mint a key for the client with the role they need, whether that is to read, to post, or to administer their own accounts. The secret is shown once.
4
You can see when a key was last used, suspend a client and restore them, and revoke a key immediately. Suspension takes effect on their 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. A partner key 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, and the ledger itself holds nothing capable of minting a credential it would accept.
Who runs ledgers for others
A seller gets their own ledger. Funds are held at checkout, and settlement across seller, platform and tax accounts is one balanced transaction.
Give each customer their own wallet or credit balance without building a ledger into your product.
Programme-level books that give each client a separate ledger, isolated by the database.
Points and stored value issued on behalf of many brands. The liability for a brand can be derived at any moment.
Keep books for several businesses under one account. None of them can see another.
Questions
No, a partner key administers a client and cannot read or write their ledger. No endpoint crosses that line. Administering a client is a different power from seeing their money.
You do, through your own plan. A client’s API calls count against it, and your clients do not need plans of their own.
Their keys are refused on the next request until you restore them. Nothing is deleted and nothing is altered, because suspension stops access without touching history.
No, the model is deliberately one level deep. The questions “whose plan pays for this call” and “who may administer this” then have one answer apiece.
Because the journal is permanent. A sandbox gives an integrator somewhere safe to make mistakes, 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.