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:


⚙️ API Export Job Configuration

Creation

To configure an export job from the DJUST back office:

Step 1 – Access the Data Hub

  1. Go to the Data Hub section.
  2. Click + Create a new job.
  3. 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 Status

When 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 status

Only 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:

  1. Go to Data Hub > Export section.
  2. Locate the job to update.
  3. 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 Found with a Location header containing the signed download URL
  • Error: 404 Not Found if 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 by supplierExternalIds (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). The supplierExternalIds field must contain at least one element.

⚠️

Important (v3.113): On POST and PUT endpoints for export jobs, the field suppliers (array of internal IDs) has been replaced by supplierExternalIds (array of external IDs). The old suppliers field is no longer accepted and returns a 400 error. On GET endpoints, the suppliers field now returns an array of objects { externalId, name } instead of an array of internal ID strings. The listing filter supplierIds has been renamed to supplierExternalIds. 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 of GET /v2/mapper/jobout/{id}. Migrate to the v2 endpoint.


Did this page help you?