Programs charge customers from a fee catalog. Catalog changes are made by the Orenda team (contact us); operators can read the catalog and produce customer-facing fee documents.

​
Reading the catalog

Both need programs.fees.catalog.view. That is deliberately not the permission a customer holds to read their own fees — these two return the whole program catalogue, including the Orenda share of each fee. The CSV columns are fixed: id, region, accountType, tier, currency, paymentType, paymentSubType, feeType, threshold, fixedFee, percentageFee, orendaFixedFee, orendaPercentageFee — the same field set POST /v1/fees/csv reads back, so a download can be edited and re-uploaded.
A cell whose value would start with =, +, - or @ is written with a leading apostrophe, so spreadsheets treat it as text rather than a formula. Strip that apostrophe if you parse the file yourself. In practice only id and tier can carry one — every other column is an enum or digits-only.
The export pages the whole catalog. It previously stopped at DynamoDB’s 1 MB read limit, so a large program’s export could be silently short. A fee row is keyed by where and what it applies to:

​
Customer-facing fee documents

GET /v1/customers/{customerId}/accounts/{accountId}/fee-reports?type=info|statement — generates a PDF (returned as a base64 data URI):
  • type=info — the fee information sheet for the customer’s region and account type. It is not narrowed to the account’s tier: a program that prices more than one tier shows every tier’s rows for that region.
  • type=statement — the fee statement for a given year (required with statement).
Errors worth handling: ACCOUNT_NOT_FOUND, APPLICATION_NOT_FOUND, NO_FEE_TRANSACTIONS (statement for a year with no fees), NO_FEES_FOR_SELECTION.