The Management API is the administrative interface to the Orenda platform — customer management, manual operations, oversight, and configuration. It’s a separate surface from the customer-facing API, with its own audience and its own documentation (this site).
Not for frontend applications. The Management API is for backend administrative systems only — never call it from customer-facing apps, mobile apps, or any client-side code. For those, see the customer API docs.

​
Two ways to call it

The Management API supports two kinds of caller, and most endpoints work with either:
  • Service user (machine-to-machine) — your backend authenticates with credentials Orenda issues and calls the API with no human in the loop (for example, inviting customers or bulk operations).
  • Operator sign-in — a person signs in (with 2FA) and acts through an admin tool.
Either way the caller’s role authorises each call. Both flows are covered in Authentication. A small number of sensitive endpoints are only supported with an operator sign-in — each such endpoint says so on its page.

​
What you can do

Invite a customer

Create a user and their application for your program with one invite call, from the back-office, with step-up.

Issuing cards for your users

End-to-end: invite a user, onboard them, issue and fund a card.

Authentication

Service-user and operator tokens, roles, and permissions.

Search

Find applications, accounts, transactions, cards, payments, charges — with CSV export.

Reports

Async report generation: transactions, customers, fees, MT940, and more.

Acting on a customer

Accounts, payments, beneficiaries, and batches on a customer’s behalf (PCI / Compliance-approved workflows only).

Card operations

Issue, block/unblock, and limits.

Fees

Read the fee catalog and generate fee documents.

Webhooks

Events Orenda pushes to you, and signature verification.

​
Conventions

  • Base URL: https://api.next.orenda.finance — the same gateway as the customer API; what makes a call administrative is the role on the token.
  • Prefer /v1 paths. Customer, account, card, payment, beneficiary and batch operations are all served on /v1. Older unprefixed paths for the same operations are still answered but are being retired, and some of them differ in method (for example card block was GET, on /v1 it is POST). A handful of surfaces — search, reports, members and roles, cross-border remittance, and a few customer-record operations — have no /v1 route yet and are documented on their unprefixed paths; those pages say so.
  • Send Authorization: Bearer <token> on every call — see Authentication. Operator sessions select the test environment with x-sandbox: true; for service users the environment is fixed by the credential.
  • Back-office endpoints are scoped to a program via a programId query parameter — ?programId=abc — on essentially every call. The program is selected by the request, not read from the token. Omitting it fails with Missing programId in query string.
  • Retry-safety: resource-creating /v1 endpoints — issuing a card, creating a payment or a beneficiary, submitting a batch — accept a UUID idempotency key, as an Idempotency-Key header (batch payments: an idempotencyKey body field). Send one on anything that moves money or issues a card. See Acting on a customer and Card operations for the exact semantics, which differ between endpoints.
  • The x-program-id header is only used by the public, pre-authentication endpoints that need it to select a program (for example POST /v1/auth/login). Each such endpoint notes it on its page.
  • Endpoints are permission-gated within your role — operator or service user alike. Orenda configures those permissions when the role is set up — a call you expect to be allowed that returns 403 means the role needs adjusting, not the request.