Backfill & Delta Load


Investor Transactions API

Backfill vs. Delta Load Guide

Close-Ended Investor Transactions | Investran

Audience: External API consumers and integration partners
Purpose: Select and process the appropriate report for initial backfill and recurring delta loads
Reports: CloseEndedInvestorTransaction – GL Date; CloseEndedInvestorTransaction – Batch Modified

1. Decision Guide

BACKFILL — Initial onboarding or a clean full reload

Report: CloseEndedInvestorTransaction – GL Date

Date controls: startDate and endDate define the transaction GL date range.

Processing: Returns historical transactions whose GL dates fall within the specified range.

DELTA LOAD — Recurring synchronization after backfill

Report: CloseEndedInvestorTransaction – Batch Modified

Date controls: The Batch Modified report applies two filters. The GL Date range (startDate/endDate) limits results to transactions whose GL dates fall within the specified range. The Batch Change Date range (batchChangeStartDate/batchChangeEndDate) determines which modified batches are returned. Both conditions are applied together, so the report is not purely based on modification date.

Processing: For batches updated within the Batch Change Date range, the API returns all associated transactions that also fall within the GL Date range. For example, if 2 of 50 transactions in a batch are modified, the response includes all 50 transactions, including the 2 updates.

Run Transaction Batch Detail for the same change window to identify batches that have been modified or should be excluded.

TRANSACTION BATCH DETAIL — Determine whether updated or deleted batches remain reportable

Endpoint: GET {Host}/v1/investran/fund/{externalId}/transactions/batchdetails

Date controls: batchModifiedBeginDate/batchModifiedEndDate, plus time parameters for greater precision.

Processing: Use reportingStatus and nonReportedBatches to retain, exclude, or soft-delete downstream records.

2. Backfill Load

The GL Date report retrieves historical investor transactions for the specified fund using the transaction GL date. Use it for initial onboarding or when a downstream platform requires a clean reload.

2.1 Request parameters

  • reportId — Required. Environment- and client-specific identifier for the GL Date report.
  • fundExternalId — Required. External identifier for the fund or legal entity.
  • startDate — Required. Earliest transaction GL date, formatted YYYY-MM-DD.
  • endDate — Required. Latest transaction GL date, formatted YYYY-MM-DD.

2.2 Sample request

POST /v1/investran/report
{
  "reportId": "<GL_DATE_REPORT_ID>",
  "fundExternalId": "23680",
  "startDate": "2006-01-01",
  "endDate": "2026-09-09"
}

2.3 Large-backfill guidance

  • Split large backfills into quarterly or half-year date ranges, or into legal-entity groups.
  • Avoid the GL Date report for recurring delta loads.

3. Delta Load

The Batch Modified report returns investor transactions associated with batches created, modified, or purged within the requested change window. Use it only after the historical backfill is established.

3.1 Request parameters

  • reportId — Required. Identifier for the Batch Modified report; distinct from the GL Date report ID.
  • fundExternalId — Required. External identifier for the fund or legal entity.
  • startDate / endDate — Required. GL date boundaries applied to transaction GL dates.
  • batchChangeStartDate — Required. Beginning of the batch-modification window, YYYY-MM-DD hh:mm:ss.zzz.
  • batchChangeEndDate — Required. End of the batch-modification window, same format.

3.2 Sample request

POST /v1/investran/report
{
  "reportId": "<BATCH_MODIFIED_REPORT_ID>",
  "fundExternalId": "23680",
  "startDate": "2006-01-01",
  "endDate": "2026-09-09",
  "batchChangeStartDate": "2026-09-08 00:00:00.000",
  "batchChangeEndDate": "2026-09-09 00:00:00.000"
}

Note: The first delta run typically begins at the completion timestamp of the backfill process. After a successful delta run, store batchChangeEndDate and use it as the next batchChangeStartDate.

4. Transaction Batch Detail

Use this API to identify updated or deleted batches and determine whether each batch should remain in downstream reporting.

Endpoint:

GET {Host}/v1/investran/fund/{externalId}/transactions/batchdetails

Date controls: batchModifiedBeginDate and batchModifiedEndDate define the modification window. Use batchModifiedBeginTime and batchModifiedEndTime for time-level precision.

4.1 Reporting status

  • Reported — Held or Posted. Retain the batch and its transactions in the downstream reporting dataset.
  • Not Reported — Draft, Deleted, or Purged. Exclude from reporting and mark or soft-delete previously stored transactions for the batch ID.

Filter behavior: Use nonReportedBatches=true for Not Reported only, or omit the parameter to return both.

4.2 Investran batch status definitions

  • Draft. Not reported by standard Investor Transactions calls.
  • Held. Reported by standard Investor Transactions calls.
  • Posted. Reported by standard Investor Transactions calls.
  • Deleted. Soft delete in Investran. Users can restore the batch to Held or Posted.
  • Purged. Hard delete from Investran reports.