This page provides an overview about import and export jobs in DJUST via SFTP or API Connector.

✅ Introduction

Data Synchronization

DJUST supports two types of data synchronization jobs:

• Import Jobs – Bring external data into DJUST.
• Export Jobs – Send data from DJUST to external systems.

Jobs can be configured to work with either:

• FTP
• API Connector
• File — import jobs only: a CSV file uploaded directly to DJUST, with no external source to configure. See Configure a File Connector.

⚠️

REST APIs

The API connector works only with REST architecture APIs and does not work with SOAP or GraphQL APIs.

Execution Modes

Jobs can be triggered in several ways:

• Manually: Triggered by an admin user from the DJUST back office (Data Hub section).
• Scheduled: Automatically run at regular intervals using cron-based scheduling (e.g., every 30 min, daily). All scheduled times are expressed in UTC.
• Event-driven (for exports): Triggered when an event occurs — typically a status change on an object like an Order.

Simultaneous execution of a job

Simultaneous execution of a job (running multiple import processes at the same time for a given job) is not allowed. This prevents data conflicts that can occur when executions modify the same records or rely on each other.

When a new execution is triggered while another is still running, the system behavior depends on the job configuration:

• RUN_IMMEDIATELY: the new execution is queued with the status JOB_PENDING and will start as soon as the previous one completes.
• WAIT_FOR_NEXT: the new execution is skipped with the status JOB_SKIPPED, and only the next scheduled execution will be considered.

This setting can be configured individually for each import job.

Duplicating a Job

You can create a copy of an existing job to quickly set up a similar import or export with the same configuration. This is useful when you need multiple jobs with similar mappings but different source files or schedules.

What is copied:

• All mapping configuration and settings from the source job.

What is not copied:

• The scheduler (cron) configuration — the new job's scheduler is reset and disabled.
• The new job is created in an inactive state.

Naming:

• The duplicated job is named {Source job name} - COPY. If that name already exists, a numeric suffix is added (e.g., - COPY (1), - COPY (2)).

API endpoint:

• POST /v1/mapper/jobs/{jobId}/duplicate — operationId: ADM-JOB-100
• Access: dj-client: OPERATOR
• Response: 200 OK with the new job's id.

{
  "id": "a9b2c3d4-e5f6-7890-abcd-ef1234567890"
}

Stopping a Job Execution

If a job execution becomes stuck or needs to be interrupted, operators can manually stop it directly from the Back-Office.

A "Stop execution" button is available on the job detail page for each execution currently in progress. The button is visible only when the execution is in one of the following stoppable statuses:

• JOB_INITIALIZING
• JOB_STARTED
• INTEGRATION_WAITING
• INTEGRATION_STARTED
• JOB_PENDING

⚠️

Warning: Stopping an execution is irreversible. A confirmation dialog is displayed before the action is performed.

Once the execution is stopped, the execution list refreshes automatically. Completed or failed executions do not display the stop button.

Requirements:

• Permission: MAPPER_WRITE

API endpoints:

• stopJobExecutionByJobStatusId — POST /v1/mapper/status/{jobStatusId}/stop — Stops a specific execution by its job status ID.
• stopLastJobExecution — Stops the last execution of a given job.

Execution ID

Each job execution (import and export) is assigned a unique execution ID. This identifier is displayed in the Back-Office:

• In the execution history list, via a dedicated column.
• In the execution detail view, below the execution date.

A Copy button allows you to copy the ID in one click to share it with DJUST support when reporting an incident.

✅

Tip: When reporting an issue on a specific job execution, always include the execution ID. This eliminates ambiguity when multiple executions occur on the same day or at similar times.

The execution ID corresponds to the jobStatusId field (for imports) or exportIntegrationId field (for exports) returned by the API. If a job has never been executed, no ID is displayed.

Execution History — Search and Filter

The execution history for both import/indexation and export jobs can be retrieved via API with search and filter capabilities:

• Search by ID: use the search query parameter to perform a partial match (contains) on the execution ID.
• Filter by status: use the statuses query parameter (multi-value) to filter executions by status. Unknown status values are silently ignored.
• Pagination: standard DJUST paginated response (content, numberOfElements, number, size, first, last, empty).
• Sorting: configurable via the sort query parameter.

Import / Indexation jobs:

• Endpoint: GET /v2/jobs/{jobId}/executions — operationId: ADM-JOB-550
• Access: dj-client: OPERATOR
• Parameters: search (partial match on execution ID), statuses (multi-value, matching job lifecycle statuses), sort (default: createdAt,desc), page, size
• Response: 200 OK

Identifying the processed source file

Each execution returned for an import job carries the source file it processed:

fileName remains available after the file itself has been purged, so the execution history stays readable over time and no extra call is needed to know which file an execution handled. This is a backward-compatible addition: no existing field of the response has been modified or removed.

{
  "content": [
    {
      "id": "3f1c8e02-5a47-4c11-9d3b-70e2a9c1b845",
      "fileName": "offers-2026-08.csv",
      "fileId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
      "status": "INTEGRATION_COMPLETED",
      "createdAt": "2026-08-20T09:15:00.000Z",
      "startedAt": "2026-08-20T09:15:02.000Z",
      "endedAt": "2026-08-20T09:16:41.000Z"
    }
  ],
  "numberOfElements": 1,
  "number": 0,
  "size": 20,
  "first": true,
  "last": true,
  "empty": false
}

✅

Tip: In the Back-Office, the file associated with an execution is displayed directly in the execution history, without any additional lookup.

Export jobs:

• Endpoint: GET /v2/jobouts/{jobOutId}/executions — operationId: ADM-JOBOUT-550
• Access: dj-client: OPERATOR
• Parameters: search (partial match on execution ID), statuses (values: SUCCESS, ERROR), sort (default: executedAt,desc), page, size
• Response: 200 OK

If no search or filter parameter is provided, all executions are returned.

Identifying the exported object

Each entry returned by ADM-JOBOUT-550 describes one export attempt on one object. Two fields let you identify that object:

Use itemId — not reference — whenever you need to fetch the exported object programmatically: it is the identifier expected by the DJUST resource APIs, so no prior lookup by reference is needed.

{
  "content": [
    {
      "id": "e7c1f2a4b93d4e51",
      "itemId": "a1b2c3d4e5f6",
      "reference": "168-123-1861251-1",
      "jobOutType": "ORDER",
      "status": "SUCCESS",
      "executedAt": "2026-08-06T09:12:45.000Z"
    },
    {
      "id": "9f3b7d18c2ae4b60",
      "itemId": null,
      "reference": "168-123-1743902-1",
      "jobOutType": "ORDER",
      "status": "ERROR",
      "executedAt": "2025-11-14T17:03:12.000Z"
    }
  ],
  "numberOfElements": 2,
  "number": 0,
  "size": 20,
  "first": true,
  "last": true,
  "empty": false
}

⚠️

Warning: itemId is null for executions that ran before the field was introduced. Historical executions cannot be linked back to their object, so always handle the null case instead of assuming an identifier is present.

✅

Tip: In the Back-Office, the reference displayed on each export execution is a direct link to the exported object's detail page. Executions with itemId: null are displayed as plain text, without a link.

Adding itemId is a backward-compatible change: no existing field of the response has been modified or removed.

⚠️

Deprecation: The following legacy endpoints remain functional but are deprecated. Migrate to the v2 endpoints listed above.

• GET /v1/mapper/status/all/{jobId} → replaced by GET /v2/jobs/{jobId}/executions
• GET /v1/mapper/jobout/{jobOutId}/exported-item-statuses → replaced by GET /v2/jobouts/{jobOutId}/executions

Import Full Mode

By default, when an import file (CSV or API Connector) sends a null or empty value for an attribute or custom field, the existing value in DJUST is preserved — the field is not modified.

When the Import Full mode is enabled on a job, the behavior changes:

• Attributes whose value is null in the import file are deleted from the target entity.
• Custom fields whose value is null are also deleted from the target entity.

This mode is useful when you need to keep your DJUST data in perfect sync with an external source system (e.g., ERP or PIM), including the removal of values that no longer exist in the source.

Configuration

The import mode is configured as a boolean parameter on import job configuration:

• Default value: false (standard mode — null values are ignored, existing data is preserved)
• Configurable at: job creation and job update
• Visible in: job read (GET /job/{id})
• Applies to: CSV/SFTP, API Connector, and Mirakl import jobs

Scope of the import mode

The import mode applies differently depending on the type of data:

• For attributes: the import mode is configured at the Product job level. When enabled, attributes with null values in the import file are deleted from the product.
• For custom fields: the import mode is configured per entity. Each of the following entity types has its own toggle: Offer, Supplier, Account, Navigation Category, Classification Category, Customer User, and Order. This allows you to enable full synchronization for some entities while keeping standard mode for others.

⚠️

Warning: Enabling Import Full mode means that any attribute or custom field not present (or set to null) in the import file will be removed from the entity in DJUST. A confirmation warning is displayed in the Back-Office before saving a job with this mode enabled. Make sure your import files contain the complete set of values you want to retain.

✅

Tip: All existing jobs retain the default behavior (standard mode). No action is required unless you explicitly want to enable full synchronization.

🧩 Entity-Based Configuration

Jobs are entity-specific, meaning each job is designed to handle a single type of data within DJUST.

The availability of each entity depends on the chosen method (SFTP or API Connector) as not all entities are supported across both.

Importable Entities per Method

Exportable Entities per Method

Automatic Export Settings

The general settings exportOrderEnabled and exportIncidentEnabled (returned by GET /v1/settings/general) are automatically managed by the platform based on export job lifecycle:

• When an export job is created (ORDER or INCIDENT), the corresponding setting is automatically activated.
• When the last export job of a given type is deleted, the corresponding setting is automatically deactivated.

These two fields are read-only via the API: they are returned by GET /v1/settings/general but silently ignored when sent in a PUT /v1/settings/general or PATCH /v1/settings/general request. No action is required from integrators — existing API calls continue to work as before.

⚠️

Warning: PUT /v1/settings/general is deprecated. Use PATCH /v1/settings/general for partial updates — only the fields you provide are modified, avoiding accidental overwrites of other settings.

✅

Tip: You do not need to manually manage these settings. Simply create or delete export jobs, and the platform keeps the settings in sync automatically.

🏪 Multi-Store Behavior

• By default, import jobs are cross-store.
• The NAVIGATION import via FTP must always be scoped to a store within the Navigation Job Configuration.
• ORDER import jobs can optionally be scoped to a specific store using the storeExternalIds parameter (via POST /v2/mapper/jobs or PUT /v1/mapper/jobs/{jobId}). When configured, all imported orders are assigned to the default store view of the specified store. Without this parameter, orders are assigned to the default store view of the tenant's default store. If the referenced store is invalid or does not exist, the job creation or update returns an HTTP 400 error.

Entity Dependencies

Some entities depend on others being imported first. While the overall import sequence can be adjusted, respecting these dependencies ensures data consistency and prevents import errors.

Here is a recommended import order based on data prerequisites:

Data Trimming

During import (both CSV/SFTP and API Connector), leading and trailing whitespace characters are automatically trimmed from all field values. Internal spaces within a value are preserved.

This applies to both import and export mapping fields.