Transaction Import/Export
This document covers bulk importing and exporting Transaction records via CSV. Transactions use the same shared import/export infrastructure as other blueprints, with additional shortcuts and handling specific to the Transaction data model.
Overview
The Transaction blueprint is composed of a flat section (Amount, Currency, Type, etc.) and several nested substep sections:
- From — the originating endpoint (contains Account → Signatory → Person/Entity)
- To — the receiving endpoint (same structure as From)
- Crypto — cryptocurrency-specific stats (Inputs/Outputs)
- Exchange — exchange rate details
- Party — additional parties (multiple allowed)
Available states for Transaction:
initialmonitoredclearedrejectedauto-rejected
Importing Transactions
Via the UI
- Navigate to the Transaction index and click + Bulk Upload
- Click Download Template to get an empty CSV with correct headers
- Fill in your records and save the CSV
- Drag the CSV onto the dropzone or click to browse
- Click Import
Via the API
POST /api_imports Content-Type: application/json { "key": "Upload
Transactions", "filename": "transactions.csv", "content_type": "text/csv",
"file_base64": "base64-encoded-csv-data" }
The
key
parameter determines which blueprint to import against. For transactions,
use
"Upload Transactions"
which targets the Transaction blueprint.
Transaction CSV Header Reference
Top-Level Fields
| Header | Type | Notes |
|---|---|---|
Key | meta | Auto-generated if blank |
State | meta | initial, monitored, cleared, etc. |
For Key | meta | Customer Key — links the transaction to a customer |
Created At | meta | Transaction date |
Amount | text | Required |
Currency | text | USD, BTC, CAD, etc. |
Type | text | Transfer, Wire, Cash, etc. |
Other Description | text | |
Credit/Debit | select | Credit or Debit |
Cash | multiselect | 1 or true to mark as cash |
Attempted | multiselect | 1 or true to mark as attempted |
Conducted | text | Transmode code / conduction type |
EFT Direction | multiselect | Initiation or Final Receipt |
Transaction Number | text | |
Internal Ref Number | text | |
Device | text | |
IP Address | text | |
Notes | text |
From Substep
The From substep describes the originating endpoint. It contains an Account substep which in turn contains a Signatory substep (multiple). Each signatory can have a Person or Entity substep.
Headers are prefixed with
From:
| Header | Type | Notes |
|---|---|---|
From My Client | multiselect | 1 or true |
From Country | select | ISO 3166-1 alpha-2 |
From Foreign Currency | text | |
From Funds Type | text | |
From Comment | textarea |
From Account Substep
Prefixed with
From Account:
| Header | Type | Notes |
|---|---|---|
From Account My Client | multiselect | 1 or true |
From Account Non-Bank Institution | multiselect | 1 or true |
From Account Account Name | text | |
From Account Account Holder | text | |
From Account Client Number | text | |
From Account Account Number | text | |
From Account Swift | text | |
From Account IBAN | text | |
From Account Institution Name | text | |
From Account Institution Code | text | |
From Account Branch | text | |
From Account Funds Code | text | |
From Account Currency Code | text | |
From Account Account Type | text | |
From Account Status Code | text | |
From Account Opened | calendar | |
From Account Closed | calendar | |
From Account Balance | text | |
From Account Date | calendar | |
From Account Country | select | ISO 3166-1 alpha-2 |
From Account Comments | textarea |
From Account Signatory Substep (Multiple)
The signatory substep is
multiple
— the first signatory uses the headers below; subsequent signatories append a
number (e.g.
From Account Signatory 2 Is Primary).
Prefixed with
From Account Signatory:
| Header | Type | Notes |
|---|---|---|
From Account Signatory Is Primary | multiselect | 1 or true |
From Account Signatory Role | text | |
From Account Signatory Person Key | key ref | Link existing Person |
From Account Signatory Person First Name | text | |
From Account Signatory Person Last Name | text | |
From Account Signatory Entity Key | key ref | Link existing Entity |
From Account Signatory Entity Name | text |
To Substep
The
To
substep mirrors the From structure exactly, with headers prefixed with
To
instead of
From:
To My ClientTo CountryTo Foreign CurrencyTo Funds TypeTo CommentTo Account Account NameTo Account Account NumberTo Account SwiftTo Account Signatory Is PrimaryTo Account Signatory Person First Name- ...and all other Account and Signatory fields
Crypto Substep
Prefixed with
Crypto:
| Header | Type | Notes |
|---|---|---|
Crypto Fiat Amount | text | |
Crypto Fiat | text | e.g. CAD |
Crypto Rate | text | Provide Rate OR Fiat Amount |
Crypto Txn Hash | text | Transaction hash |
Crypto Inputs / Outputs (Multiple)
Both
Inputs
and
Outputs
are multiple substeps under Crypto. Prefixed with
Crypto Inputs
and
Crypto Outputs:
| Header | Type | Second Instance |
|---|---|---|
Crypto Inputs Amount | text | Crypto Inputs 2 Amount |
Crypto Inputs Address | text | Crypto Inputs 2 Address |
Crypto Outputs Amount | text | Crypto Outputs 2 Amount |
Crypto Outputs Address | text | Crypto Outputs 2 Address |
Exchange Substep
Prefixed with
Exchange:
| Header | Type | Notes |
|---|---|---|
Exchange Quote Amount | text | |
Exchange Quote Currency | text | e.g. CAD |
Exchange Rate | text | Provide Rate OR Quote Amount |
Party Substep (Multiple)
The Party substep is
multiple. First party uses base headers; subsequent parties append a number (Party 2 Type, etc.).
Prefixed with
Party:
| Header | Type | Second Instance |
|---|---|---|
Party Key | text | Party 2 Key |
Party Type | select | Party 2 Type |
Party Name | text | Party 2 Name |
Party Address | text | Party 2 Address |
Party Country | select | Party 2 Country |
Party Code | text | Party 2 Code |
Party Relationship | select | Party 2 Relationship |
Slim Headers (Shorthand)
Transactions support
slim headers
as a shorthand for the full nested column names. Instead of writing
From Account Signatory Person First Name, you can write
From First Name. The importer automatically expands slim headers to their full form by
detecting whether the referenced record is a Person or Entity based on the
fields provided:
| Slim Header | Expands To |
|---|---|
From First Name | From Account Signatory Person First Name |
From Last Name | From Account Signatory Person Last Name |
From Name | From Account Signatory Entity Name |
From Birthdate | From Account Signatory Person Birthdate |
To First Name | To Account Signatory Person First Name |
To Last Name | To Account Signatory Person Last Name |
To Name | To Account Signatory Entity Name |
To Nature of Principal Business | To Account Signatory Entity Nature of Principal Business |
The importer detects whether the slim header refers to a Person or Entity by
checking the data. If both
From First Name
and
From Last Name
are present, it expands to Person. If only
From Name
is present (without first/last), it expands to Entity. If a
From Key
or
To Key
column links to an existing step, the step's kind determines Person vs
Entity. When the type cannot be determined, Person is the default.
You can mix slim and full headers in the same CSV. Full headers take precedence and are not overwritten by the expansion.
Conductor & Beneficiary Shorthand
Instead of providing the full signatory key chain, you can use these shorthand columns to link existing records:
| Column | Expands To |
|---|---|
Conductor Person | From Account Signatory Person Key |
Conductor Entity | From Account Signatory Entity Key |
Beneficiary Person | To Account Signatory Person Key |
Beneficiary Entity | To Account Signatory Entity Key |
These columns accept a Step Key value and automatically link it to the correct account signatory on the From or To side.
Key References
Instead of providing full field data for a substep or signatory, you can reference an existing record by its Key. For example:
From Account Signatory Person Key— link an existing Person as the signatoryFrom Account Signatory Entity Key— link an existing Entity as the signatoryFor Key— link the transaction to an existing Customer
If the referenced key is not found, the substep data will be blank (no error is raised).
Exporting
- Go to the Transaction index view
- Apply any search filters (state, date range, keyword query, etc.)
- Click the Export button
The export:
- Applies the current search/filter criteria
- Generates a CSV with the same headers the import expects
- Strips empty columns — only populated columns appear
- Supports up to 10 instances of multiple-value fields (signatories, parties, crypto inputs/outputs)
- Uses the full header format (not slim headers)
Template Generation
Click Download Template from the Bulk Upload page to get an empty CSV with all possible headers. The template includes:
- Every field defined on the Transaction blueprint
- All nested substep columns (From, To, Crypto, Exchange, Party)
- Second-instance headers for multiple substeps (Signatory 2, Party 2, etc.)
- A
$refheader for key-based references on substeps
Bulk Delete
- Go to Top Menu → Imports → Import Row
- Find the import record (shows the record kind and timestamp)
- Click Delete Imported Records
This deletes every step created with that import's
import_id, allowing you to cleanly retry failed or incorrect imports.
Date Formats
The importer accepts these date formats:
2023-10-252023-10-25 00:00:00 UTCWed, 25 Oct 2023 00:00:00 +00002021-07-03T23:21:48.007Z2007-04-05T12:30-06:008/27/2024(US-centric, m/d/Y)8/9/24(US-centric, m/d/y)08/27/2024 00:0008/27/24 00:00
When in doubt, create a record via the UI, export it, and copy the format used.
Important Notes
- Row order — rows will be processed in the order of the created date.
- Batch large imports — split very large uploads into multiple files
- Best practice: Create a single transaction in the UI, export it to see the format, then model your bulk import on that export
- Slim headers and conductor/beneficiary shorthands are import-only; exports always use the full header format