> ## Documentation Index
> Fetch the complete documentation index at: https://developers.pleo.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Retrieve Export Job Items

export const RememberCallout = ({title, children, icon = "🪢"}) => <div style={{
  backgroundColor: 'var(--recommended-bg)',
  borderLeft: '4px solid #f63b92',
  borderRadius: '10px',
  padding: '18px 22px',
  marginBottom: '20px',
  boxShadow: '1px 1px 3px rgba(0,0,0,0.06)'
}}>
    <div style={{
  display: 'flex',
  alignItems: 'flex-start',
  gap: '14px'
}}>
      <span style={{
  fontSize: '22px',
  lineHeight: '1',
  flexShrink: 0
}}>
        {icon}
      </span>
      <div>
        {title && <div style={{
  fontSize: '16px',
  fontWeight: 600,
  color: 'var(--recommended-title)',
  marginBottom: '6px'
}}>
            {title}
          </div>}
        <div style={{
  fontSize: '14px',
  lineHeight: 1.65
}}>
          {children}
        </div>
      </div>
    </div>
  </div>;

This page describes how integrations retrieve **Export Job Items** after an Export Job has been started.

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:

* [How to Retrieve Export Job Items for Processing](/docs/current/how-tos/accounting-integrations/how-to-retrieve-export-job-items-for-as-erp-processing)

## Purpose

* Retrieve all Export Job Items associated with an in-progress 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:

| Layer                     | Responsibility                   |
| ------------------------- | -------------------------------- |
| Control Layer (this step) | Identify items and track status  |
| Data Layer                | Retrieve full accounting payload |

This step operates **only on control data**.

<callout icon="💡" color="gray_bg">
  Export Job Items do not contain full accounting data. Use the Export Items endpoint to retrieve processing payloads.
</callout>

## Retrieving Export Job Items

Use the **Get Export Job Items** endpoint with the `jobId` of the in-progress Export Job.

```http theme={null}
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.

### Recommended Filtering

Only process items with:

* status = `pending`
* status = `in_progress`

```pseudo theme={null}
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

```pseudo theme={null}
items = []

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

<RememberCallout title="Remember">
  Processing a partial dataset may result in incomplete exports and inconsistent state.
</RememberCallout>

## 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

```pseudo theme={null}
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 started (`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?

* [Fetch Export Item Data](/docs/current/integration-design/exports/integration-design-exports-fetch-export-items-data-layer)

***

## Related Reading

* [How to Retrieve Export Job Items for Processing](/docs/current/how-tos/accounting-integrations/how-to-retrieve-export-job-items-for-as-erp-processing)
* [Export Integration Workflow Guide](/docs/current/guides/export-integration-workflow-guide)
* [AS/ERP Processing Workflow Guide](/docs/current/guides/accounting-system-processing-workflow-guide)

***