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

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

💡
Hybrid method available for API Connector
You can configure an API Connector to retrieve a .csv file by making a GET request to a URL returned by a previous API call.

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).
Event-driven (for exports): Triggered when an event occurs — typically a status change on an object like an Order.

Simultaneous execution of a job

A simultaneous execution of a job refers to multiple import processes being run at the same time for a given job. This can lead to data conflicts, especially when the executions modify the same records or rely on each other.

You can enable or disable simultaneous execution by contacting the support team.

Additionally, when simultaneous executions are disabled, you can configure how the system behaves when a new execution is triggered while another is still running:

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.

🧩 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

Entity	SFTP	API Connector
Account	✅	✅
Assortment	✅	✅
Attribute	✅	❌
Classification	✅	❌
Customer user	✅	❌
External Order	✅	❌
Incident	❌	✅
Navigation	✅	❌
Offer	✅	✅
Update Order	✅ (Status only)	✅
Product	✅	✅
Product tag	✅	❌
Related product	✅	❌
Store	✅	❌
Supplier	✅	✅

Exportable Entities per Method

Entity	SFTP	API Connector
Order	✅	✅
Incident	❌	✅

🏪 Multi-Store Behavior

By default, import jobs are cross-store
The only exception is the NAVIGATION import via FTP, which must always be scoped to a store within the Navigation Job Configuration.

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:

Entity	Prerequisites	Notes
Attribute	—	Must be created before using in classifications or products.
Supplier	—	Required before Offers.
Account	—	Represents a B2B customer entity.
Store	—	Represents a store in the merchant website
Classification	Attribute	Needed before importing Navigation or Products.
Navigation	Classification	Relies on existing classification structure.
Product	Classification	Must be imported before Offers, Tags, and Assortments.
Offer	Product, Supplier	Links a product to a supplier with commercial terms.
Product Tag	Product	Cannot be imported before products exist.
Related Product	Product	Cannot be imported before products exist.
Assortment	Product	Assortments group products and require products to be available.
Customer User	Account	A user is always linked to an existing account.

📌
Best Practices
✔️ Only run jobs for data that has actually changed. Avoid full re-imports unless necessary, especially for large catalogs.
✔️ Importing entities in the correct order helps avoid failures due to missing references