Skip to main content
This page describes how integrations retrieve Export Job Items after an Export Job has been claimed. Export Job Items represent the control layer of the export workflow. They define which items must be processed and track processing state, but do not contain full accounting data.

​
Implementation

See the corresponding how-to article for API usage and step-by-step instructions:

​
Purpose

  • Retrieve all Export Job Items associated with a claimed Export Job
  • Determine the scope of processing
  • Track per-item processing state
  • Enable resumable and idempotent workflows

​
Control Layer vs Data Layer

Export processing is split into two distinct responsibilities:
LayerResponsibility
Control Layer (this step)Identify items and track status
Data LayerRetrieve full accounting payload
This step operates only on control data.

​
Retrieving Export Job Items

Use the Get Export Job Items endpoint with the jobId of the claimed Export Job. 
GET /v3/export-jobs/{jobId}/items
This endpoint returns control data for each item, including:
  • accountingEntryId (unique identifier)
  • status (e.g. pending, in_progress, successful, failed)
  • export tracking fields (externalId, failureReason, etc.)

​
Processing Scope

Export Job Items define which entries require processing. At the start of the workflow:
  • All items are typically in pending state
  • The Export Job is in_progress
The integration should determine which items require work. Only process items with:
  • status = pending
  • status = in_progress
itemsToProcess = filter items where status == "pending" or status == "in_progress"

​
Pagination

Export Job Items may be returned across multiple pages. Integrations must retrieve all pages before beginning processing.

​
Example Pagination Response

{
  "pagination": {
    "hasNextPage": true,
    "endCursor": "<cursor>"
  }
}

​
Example Pseudo

items = []

do:
    response = fetchItems(cursor)
    items.append(response.data)
    cursor = response.pagination.endCursor
while response.pagination.hasNextPage

​
Resumability & Recovery

Export workflows must be resilient to interruptions (e.g. crashes, network failures). If the integration restarts:
  • The Export Job may already be in_progress
  • Some Export Items may already be processed

​
Recovery Strategy

  1. Re-fetch all Export Job Items
  2. Filter for items still requiring processing
  3. Resume from the last known state
itemsToProcess = filter items where status == "pending"
This ensures the workflow is:
  • resumable
  • idempotent
  • consistent

​
Deterministic Processing Order

Export Items should be processed in a stable and predictable order. Recommended strategies:
  • chronological ordering (e.g. oldest transaction date)
  • consistent ordering across retries
Deterministic ordering improves:
  • reconciliation
  • debugging
  • auditability

​
Idempotency Considerations

The integration must ensure that processing is safe to retry. Recommended practices:
  • Treat accountingEntryId as the unique identifier
  • Avoid reprocessing items that are already completed
  • Maintain local tracking if necessary

​
Expected Outcome

After completing this step:
  • All Export Job Items have been retrieved
  • Processing scope is clearly defined
  • Pagination has been resolved
  • The workflow is resumable and deterministic
  • No accounting data has been processed yet

​
Upstream Dependencies

  • Export Job has been claimed (status = in_progress)
  • Integration authentication is configured

​
Downstream Dependencies

  • Fetch Export Item Data (data layer)
  • AS/ERP processing workflow
  • Export Item & Job status updates

​
What Comes Next?