Create a Transaction if none exists with the given Tracking ID, or update the existing one otherwise.
This is an idempotent operation: calling it twice with the same payload results in the same end state. Safe to retry on network failure, or to replay as part of a scheduled sync from your portfolio accounting system or fund administrator's monthly data.
Matching rule
The Transaction is matched by the trackingId you supply in the request body. trackingId is required — requests without a trackingId are rejected with a 400 Bad Request.
Response
The response always includes the full Transaction object plus a result field:
"result": "created"— no match was found, a new Transaction was created under the suppliedinvestmentId."result": "updated"— an existing Transaction was found and its fields were updated.
Field semantics
| Field | Create | Update |
|---|---|---|
trackingId | Required (match key). | Required (match key). |
name | Required. | Replace if present; omit = unchanged. |
transactionType | Required. | Replace if present; omit = unchanged. |
investmentId | Required. | Ignored — Transactions are tied to their investment for life. |
amount, fundFeeId, effectiveDate, createdDate, note | Optional. | Replace if present; omit = unchanged. |
Validation errors return 400 Bad Request with the offending field name.
Bulk upsert mode (caveat)
When using mode: "upsert" on the bulk POST /transactions/import endpoint, every per-row field is applied to the matched Transaction — there is no way to express "leave this field unchanged" within a single bulk row. Use the individual upsert endpoint above for partial updates.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||