# Get Export Job Status

## Overview
The Content Export Status API provides real-time status information to monitor job progress and check completion status.
## Status Values
- **Pending**: Job is pending start of processing
- **In Progress**: Job is actively processing content
- **Completed**: Job finished successfully
- **Failed**: Job encountered errors and could not complete

## Response Information
- **Current Status**: Real-time job status
- **Progress Metrics**: Items processed, total items
- **Error Details**: Specific errors encountered during processing
- **Timing Information**: Start time, estimated completion, actual completion

## Permission
* Only a client application can invoke this API.

## License
* This API requires a site license (SKU: EG-CL-RTKA-PT).

Endpoint: GET /content/export/{jobID}/status
Security: oAuthClient

## Path parameters:

  - `jobID` (string, required)
    **Example Usage:**
```bash
GET /content/export/7A84B875-6F75-4C7B-B137-0632B62DB0BD/status
```

## Header parameters:

  - `Accept-Language` (string, required)
    The Language locale accepted by the client (used for locale specific fields in resource representation and in error responses).

## Response 200 fields (application/json):

  - `status` (string, required)
    Enum: "Pending", "In Progress", "Successful", "Failed"

  - `progress` (object)
    Details about the job's progress.

  - `progress.processed` (integer)
    The number of items processed so far.
    Example: 1500

  - `progress.total` (integer)
    The total number of items to process.
    Example: 4500

  - `progress.percentage` (number)
    The percentage of the job that is complete.
    Example: 30

  - `startTime` (string)
    The timestamp when the job started.
    Example: 2025-09-15T10:00:00.000Z

  - `estimatedCompletion` (string)
    The estimated timestamp when the job is expected to finish.
    Example: 2025-09-15T11:30:00.000Z

  - `completionTime` (string)
    The timestamp when the job completed.
    Example: 2025-09-15T11:25:00.000Z

  - `failureTime` (string)
    The timestamp when the job failed.
    Example: 2025-09-15T10:45:00.000Z

  - `results` (object)
    Breakdown of completed job results.

  - `results.successful` (integer)
    The count of successfully processed items.
    Example: 4485

  - `results.warnings` (integer)
    The count of items with warnings.
    Example: 10

  - `results.errors` (integer)
    The count of items with errors.
    Example: 5

  - `error` (string)
    A description of the job failure reason.
    Example: Connection timeout after processing 1500 items.

## Response 400 fields (application/json):

  - `code` (string, required)
    A string that follows the pattern *{integer}-{integer}*.
The first *{integer}* is the http status code.  This code as a whole is unique.
* For example, error codes "400-101" and "404-101" are distinctly different.

  - `developerMessage` (string, required)
    A summary of the error.

  - `details` (array)

  - `details.key` (string, required)

  - `details.value` (string)

  - `userMessage` (string)
    UI friendly messages are only supported by some APIs.
* The client must explicitly request UI friendly messages by passing the *X-egain-error-message=yes* header.

## Response 401 fields (application/json):

  - `code` (string, required)
    A string that follows the pattern *{integer}-{integer}*.
The first *{integer}* is the http status code.  This code as a whole is unique.
* For example, error codes "400-101" and "404-101" are distinctly different.

  - `developerMessage` (string, required)
    A summary of the error.

  - `details` (array)

  - `details.key` (string, required)

  - `details.value` (string)

  - `userMessage` (string)
    UI friendly messages are only supported by some APIs.
* The client must explicitly request UI friendly messages by passing the *X-egain-error-message=yes* header.

## Response 403 fields (application/json):

  - `code` (string, required)
    A string that follows the pattern *{integer}-{integer}*.
The first *{integer}* is the http status code.  This code as a whole is unique.
* For example, error codes "400-101" and "404-101" are distinctly different.

  - `developerMessage` (string, required)
    A summary of the error.

  - `details` (array)

  - `details.key` (string, required)

  - `details.value` (string)

  - `userMessage` (string)
    UI friendly messages are only supported by some APIs.
* The client must explicitly request UI friendly messages by passing the *X-egain-error-message=yes* header.

## Response 404 fields (application/json):

  - `code` (string, required)
    A string that follows the pattern *{integer}-{integer}*.
The first *{integer}* is the http status code.  This code as a whole is unique.
* For example, error codes "400-101" and "404-101" are distinctly different.

  - `developerMessage` (string, required)
    A summary of the error.

  - `details` (array)

  - `details.key` (string, required)

  - `details.value` (string)

  - `userMessage` (string)
    UI friendly messages are only supported by some APIs.
* The client must explicitly request UI friendly messages by passing the *X-egain-error-message=yes* header.

## Response 500 fields (application/json):

  - `code` (string, required)
    A string that follows the pattern *{integer}-{integer}*.
The first *{integer}* is the http status code.  This code as a whole is unique.
* For example, error codes "400-101" and "404-101" are distinctly different.

  - `developerMessage` (string, required)
    A summary of the error.

  - `details` (array)

  - `details.key` (string, required)

  - `details.value` (string)

  - `userMessage` (string)
    UI friendly messages are only supported by some APIs.
* The client must explicitly request UI friendly messages by passing the *X-egain-error-message=yes* header.

