Job Configuration - Export - API Connector
This documentation describes how to configure an Export Job using the API Connector to push data to an external REST API in JSON format.
✅ Prerequisites
Before creating an export job, ensure you have:
- A configured API Client. See how to configure an API client.
- An endpoint ready to receive exported orders in your system.
⚙️ API Export Job Configuration
Creation
To configure an export job from the DJUST back office:
Step 1 – Access the Data Hub
- Go to the Data Hub section.
- Click + Create a new job.
- Select Export.
Step 2 – Job configuration
Basic information
- Job name (must be unique)
- Export method: API Client
- Client Connection
- Object to export: e.g. Order
- Trigger status(es)
Trigger StatusWhen an entity reaches one of the selected statuses for the first time, an export is triggered. If the status remains unchanged, no further export will occur — regardless of whether there are changes on the entity or not.
For more details about Order statuses, refer to this page: Order lifecycle and statuses.
Allow export multiple times for a same statusOnly available for status ORDER_DRAFT_ON_HOLD
It is possible to export the same order multiple times for the status ORDER_DRAFT_ON_HOLD.
Available upon request.
Api calls
- Configure the API calls that DJUST will use to push data to your system.
- Choose the HTTP method that matches your endpoint's requirements.
- Define optional query parameters
Mapping
- Map each field from DJUST field to your API body parameter to ensure proper alignment.
For more details on how to configure mappings for each data entity, refer to:
Manage and Update
Once your API export job is created, you can manage it via the Data Hub interface:
- Go to Data Hub > Export section.
- Locate the job to update.
- Click the ⚙️ icon to open the configuration.
Update
You can update the following settings:
- Client Connection
- Trigger status(es)
- API endpoint, HTTP method and query parameters
Delete
- Select Delete job and confirm (⚠️ This action is irreversible)
📄 Exported JSON Structure
The payload pushed to your endpoint depends on the exported object. The structure, a payload example and the list of fields available for mapping are documented on the dedicated mapping pages:
📥 Downloading Exported Files
Each file generated during an export execution (API Connector JSON) is automatically archived before the delivery attempt. This allows operators to download and verify the exact data that was sent — or to retrieve files in case of delivery failure.
Endpoint: GET /v2/jobouts/executions/{executionId}/exported-file/signed-url — operationId: ADM-JOBOUT-501
- Access:
dj-client: OPERATOR - Response:
302 Foundwith aLocationheader containing the signed download URL - Error:
404 Not Foundif the file is absent or has expired
The archived file is named exported-file-{exportIntegrationId}.{extension} for easy identification when downloading multiple files.
The signed URL is valid for 24 hours. Archived files are retained for 90 days and then automatically deleted. Only exports performed after this feature was enabled are archived.
🔁 Retry Logic
If the export fails (e.g., due to API unavailability or a 500 error), DJUST will:
- Retry the export up to 5 times
- Use a fixed interval of 15 minutes between retries
If all attempts fail, the job is marked as failed, and an operator should investigate.
🧠 Key Business Rules
- The export is triggered only once per status per Order Logistic.
- Only one endpoint per export job is supported.
- No filtering on exported data by account or store. However, export jobs can be configured with one or more suppliers, and the job listing API (
GET /v1/mapper/jobout) supports filtering bysupplierExternalIds(multi-value, OR logic).
Supplier Management on Export Jobs
Export jobs can be scoped to specific suppliers. In addition to the full replacement via PUT, two partial operations are available to manage suppliers without overwriting the entire job configuration:
Add suppliers — PATCH /v2/jobouts/{jobOutId}/suppliers — operationId: ADM-JOBOUT-200
- Merges the provided suppliers into the existing list. Duplicates are silently ignored.
- Body:
{ "supplierExternalIds": ["SUP-ACME-001", "SUP-BETA-002"] } - Response:
204 No Content - Access:
dj-client: OPERATOR
Remove suppliers — DELETE /v2/jobouts/{jobOutId}/suppliers — operationId: ADM-JOBOUT-300
- Removes the provided suppliers from the existing list. Absent suppliers are silently ignored.
- Body:
{ "supplierExternalIds": ["SUP-ACME-001"] } - Response:
204 No Content - Access:
dj-client: OPERATOR
Warning: If all suppliers are removed from an export job, the job exports orders for all suppliers (default behavior). ThesupplierExternalIdsfield must contain at least one element.
Important (v3.113): OnPOSTandPUTendpoints for export jobs, the fieldsuppliers(array of internal IDs) has been replaced bysupplierExternalIds(array of external IDs). The oldsuppliersfield is no longer accepted and returns a400error. OnGETendpoints, thesuppliersfield now returns an array of objects{ externalId, name }instead of an array of internal ID strings. The listing filtersupplierIdshas been renamed tosupplierExternalIds. The list of returned suppliers is filtered based on the stores accessible by the connected operator.
Deprecation:GET /v1/mapper/jobout/{jobOutId}is deprecated in favor ofGET /v2/mapper/jobout/{id}. Migrate to the v2 endpoint.
Updated 25 days ago

