Loaded Files

Load transactions into Class in bulk, from your own system.

If your system already holds transaction data — bank statements, contract notes, income, corporate actions — this is how you get it into Class. You build a file of transactions, submit it in one request, and poll for the result. A single file can carry up to 5,000 transactions, spanning as many funds as you need.

It is the programmatic equivalent of the Class Excel Transaction Loader. Files submitted here appear in Browse Loaded Files on the Class application.

What you can load

Interface code	Transactions
`StagedGenericCash`	Bank statement lines, expenses and custom-holding transactions
`StagedGenericStockMovement`	Acquisitions, disposals, in-specie transfers, capital calls and returns
`StagedGenericIncome`	Dividends, distributions, interest and rebates
`StagedGenericCorporateAction`	Buybacks, spin-offs, splits, consolidations, takeovers and mergers
`StagedGenericTermDeposit`	Term deposit acquisitions, redemptions and bank fees
`StagedGenericSecurityIssue`	Unit and security prices

One file carries one interface code. Within that file the transactions may span many funds, many brands and many event types.

How a submission is put together

A submission has two layers.

The data file holds the transactions. It is an ordinary JSON document — an interface code, and an array of items — but you never send it on its own. It travels Base64-encoded inside the envelope.

{
  "InterfaceCode": "StagedGenericCash",
  "TransformedItems": [
    {
      "SourceTransactionId": "850004",
      "HoldingAccount": {
        "Code": "CBA-OPERATING",
        "FundCode": "SMF001",
        "BrandCode": "MYBRAND",
        "EventTypes": [
          {
            "EventTypeName": "BankStatementLineItem"
          }
        ]
      },
      "TransactionDate": "2026-07-01",
      "DebitCreditIndicator": "C",
      "TransactionAmount": 1500.0,
      "Description": "Member contribution"
    }
  ]
}

The envelope is what you POST. It carries a label for the submission, the interface code again, and the encoded data file in Payload.

{
  "Request": {
    "RequestId": "June bank statements",
    "InterfaceCode": "StagedGenericCash"
  },
  "Payload": "eyJJbnRlcmZhY2VDb2RlIjoiU3RhZ2VkR2VuZXJpY0Nhc2gi..."
}

InterfaceCode is the one thing that appears in both, and the two must match or the submission is rejected with STAGING_INTERFACE_CODE_MISMATCH.

Note that the fund and the brand belong to each transaction's holding account rather than to the file. That is what allows a single submission to span several funds.

Which fund a file belongs to

Every operation exists at two scopes.

At business scope a file may carry transactions for any fund in the business, and each item names its own FundCode.

At fund scope the fund comes from the URL, so FundCode may be omitted from the items. If you do supply it, it must match the fund in the route, or the submission is rejected with STAGING_FUND_ROUTE_MISMATCH.

Market price files are the exception. They may only be submitted at business scope, and no item may carry BrandCode.

What happens after you submit

Submitting does not load the transactions. It hands Class a file to work through, and returns a FileId straight away. Processing happens afterwards, and you poll for the outcome.

Submitting and polling covers the full round trip, including how to tell success from failure and what to do when individual transactions fail.

Where to go next

Structure and encoding — the shared rules and the Base64 step
Data files — fields and worked examples for each interface code
Submitting and polling — the request lifecycle
API reference — every operation, parameter and error code

Authentication, credentials and environments are covered in Resources.