Mental model
The integration pattern is straightforward:- Authenticate with an API key (
rmf_test_/rmf_live_) - Create a payment intent (swap or payment route), optionally tied to a customer
- Fund the deposit address returned by the API
- Track status until settled
- Reconcile via
GET /v1/transactions— filter bycustomerIdwhen needed
Core objects
| Object | Purpose |
|---|---|
| Organisation | Your tenant. Created at signup. Gets a primary customer automatically. |
| Customer | A payer or counterparty under your org. Swaps and payment routes are tied to a customer. |
| Swap | Same-chain stablecoin conversion with a time-bound deposit address. |
| Payment route | Cross-chain collection route with a persistent deposit address. |
| Transaction | Ledger row linking swaps and route deposits for reporting. |
| API key | Scoped programmatic access (fx:read, transfers:write, collections:write, etc.). |
Authentication layers
| Audience | Auth | Used for |
|---|---|---|
| Dashboard users | JWT (email + OTP) | Signup, login, API key management |
| Integrations | API key (Bearer) | Swaps, routes, customers, rates, transactions |
https://api.remitflex.io/v1
Products
| Product | Typical use |
|---|---|
| Swaps | Same-chain stablecoin conversion (e.g. USDC → EURC on Solana) |
| Payment routes | Cross-chain pay-in (e.g. collect on Ethereum, deliver on Solana) |
Scopes
API keys use fine-grained scopes. Grant only what each service needs:| Scope | Access |
|---|---|
fx:read | Rates |
transfers:read | Read swaps, customers, transactions |
transfers:write | Create/cancel swaps, create customers |
collections:read | Read payment routes and deposits |
collections:write | Create and manage payment routes |
What we do not do yet
- Fiat bank off-ramp (NGN, KES, etc. to local bank accounts)
- Outbound merchant webhooks
- Self-serve API key creation via API key (keys are created in the dashboard)