Program capabilities

The Orenda API is one API. Some features are optional, and a few limits change from one program to another. You don’t need to know anything about how a program is powered — you just need to know what your program can do. Ask the API:

GET /v1/capabilities
Authorization: Bearer <access_token>

It takes no parameters. Your program, your environment and your accounts all come from the token. Call it once when your app starts and cache it for the session.

{
  "success": true,
  "data": {
    "programId": "examplebank",
    "sandbox": false,
    "program": {
      "payments": {
        "batch": true,
        "international": false,
        "directDebit": { "sepa": true }
      },
      "beneficiaries": { "stepUpMethods": ["passkey", "totp"] }
    },
    "accounts": [
      {
        "accountId": "3f1c9b7e-1f4a-4d2b-9c11-2f8a6b0e4d31",
        "currency": "GBP",
        "region": "UK",
        "details": ["sortCode", "accountNumber"],
        "payments": {
          "reference": { "min": 0, "max": 35, "charset": "letters, digits, spaces and / - ? : ( ) . , ' +" },
          "feePreview": true
        },
        "beneficiaries": { "addressRequired": false },
        "operations": { "block": true, "unblock": true, "close": true },
        "cards": { "limits": { "mode": "custom" } }
      }
    ]
  }
}

See the API reference for the full schema.

Two halves, and why

program holds the capabilities that apply whatever account you use. accounts holds the ones that depend on which account you’re operating on. That split is not cosmetic. A single program can hold a UK account and an EU account served by different banks, and those two accounts have genuinely different answers: different reference limits, sometimes different rules for adding a payee. So:

Read the account entry for the account you’re about to use. Don’t read accounts[0] and apply it to all of them.

What’s in there

Per program

Field	Meaning
`payments.batch`	Batch payments are available. When `false`, those endpoints return `501 not_available`.
`payments.international`	International payments and FX quotes are available. When `false`, the transfer endpoint returns `501 not_available`.
`payments.directDebit.sepa`	SEPA direct debit collection is enabled.
`beneficiaries.stepUpMethods`	Which confirmation methods you may send when adding a payee. Sending one that isn’t listed is rejected with a `400`.

stepUpMethods is the one field that reflects your session as well as your program. On a program enrolled in passkey-only step-up, an SSO session is restricted to passkey, and the list says so. Read it per session rather than caching it against the program.

Per account

Field	Meaning
`payments.reference`	The `min`, `max` and character set for the payment reference. This is the one most likely to trip you up — it is commonly 35 on one account and 140 on another in the same program. Going over is rejected.
`payments.feePreview`	You can preview a fee before sending. When `false`, that endpoint returns `501 not_available`.
`beneficiaries.addressRequired`	A payee `address` (`line1`, `city`, `country`) is mandatory when adding a payee. When `true`, leaving it out is rejected.
`operations.block` / `unblock` / `close`	Which account lifecycle operations are available. A `false` means that endpoint returns `501` instead of acting.
`cards.limits.mode`	How this account’s card limits are edited. `custom`: set the values per card through the card policy endpoints. `preset`: pick a profile with update limit group. Omitted when the account has no cards.
`details`	Which identifier fields this account has — `iban`, `bic`, `sortCode`, `accountNumber`, or a combination. Read what’s present rather than assuming a format.
`region`	`UK`, `EU` or `GLOBAL`. Omitted when the account isn’t tied to a region; that’s not an error, and the reference limits shown are still exactly what will be enforced.

What `accounts` contains

Every account you hold, across every customer on your token — so a guardian or corporate manager sees all of them. Pending and closed accounts are omitted, matching what GET /v1/accounts returns. An empty accounts array always means you hold none. It is never a silent read failure, and it is what you get on a token with no customer context; the program block is still valid.

This describes your program, not your user

Some endpoints are also restricted by the signed-in user’s role. payments.batch is the one to watch: it tells you whether the program has batch payments, not whether this user may use them. A user whose role doesn’t include batch access will still get a 403.Handle role-level 403s as you would any permission error — the capability document won’t predict them.

Still worth knowing

A few things aren’t in the capability document:

Currencies and rails. Call GET /v1/payments/currencies for the list.
Payee details you send. Send what the payee’s account uses — an IBAN (sometimes with a BIC), or a sort code and account number. The API checks you’ve sent the right ones.
501 not_available in general. Treat it as “this feature is off for me”, the same way you’d treat a feature flag — not as an outage.

A good habit

Write your integration so it reacts to the data:

Read /v1/capabilities once at start-up, and branch on it instead of hard-coding.
Look up the account entry for the account in hand.
Read the fields that are present, instead of expecting a fixed shape.

Do that, and the same code works for every program with no special cases.

Get started

Guides

Program capabilities

Two halves, and why

What’s in there

Per program

Per account

What `accounts` contains

This describes your program, not your user

Still worth knowing

A good habit

​Two halves, and why

​What’s in there

​Per program

​Per account

​What accounts contains

​This describes your program, not your user

​Still worth knowing

​A good habit

Two halves, and why

What’s in there

Per program

Per account

What `accounts` contains

This describes your program, not your user

Still worth knowing

A good habit