Enrich your core / CRM with transactional data

Goal. Land member investment activity — orders, dividends, and IRA cash movements — into your core or CRM, keyed by member.

Endpoint. Get transaction list with date filters and pagination.

Incremental sync pattern.

1. Track a last_synced_at watermark per run.
2. Call Get transaction list with transacted_at_start=<last_synced_at>, transacted_at_end=<run_start_time>, per_page=your batch size, last_record_number=0.
3. Write each item to the core/CRM, keyed by transaction_id (use it as the idempotency key — upsert, don't insert blindly).
4. Page: repeat the call with the last_record_number from each response until you have pulled total_records items.
5. Advance the watermark to <run_start_time>.

Both transacted_at bounds are inclusive, so a record stamped exactly on the boundary appears in consecutive windows — harmless, because you upsert on transaction_id.

Fields worth mapping. type (order, dividend, ira), transaction_name (buy, sell, dividend, contribution, distribution), amount, fee, product, symbol, status, transacted_at, completed_at, trading_period_id. Filter with type= if you only want one category of activity.

transaction_name is what distinguishes direction within a category — an IRA contribution from a distribution, or a buy from a sell. amount is unsigned, so book entries off transaction_name rather than the sign of the value.

Status changes. A transaction can move from pending to a terminal state between runs. Because you key on transaction_id and upsert, a later run that re-sees the transaction with updated status / completed_at corrects the record.