Getting Started

This page describes the conventions shared by every DSWMS integration endpoint. Read it before the individual interface pages.

Base URL

All endpoints are served over HTTPS from the DSWMS integration service:

https://{url}

The host for each environment (test and production) is provided by DSWMS during onboarding. Every path in this documentation is relative to it and starts with the API version, for example https://{url}/v1/articles.

Authentication

Every request must be authenticated with HTTP Basic authentication.

Credential	Value
Username	Numeric client ID issued by DSWMS, for example 42
Password	API key issued by DSWMS together with the client ID

POST /v1/articles HTTP/1.1
Host: {url}
Authorization: Basic NDI6eW91ci1hcGkta2V5
Content-Type: application/json

The API is stateless: no session is created, and the credentials must be sent with every request.

The client determines the organization the data belongs to. Articles, orders and other records are always identified within that client, so the same external identifier can safely exist for other clients.

Requests without credentials, or with an unknown client ID or a wrong API key, are rejected with 401 Unauthorized. The body of this response is plain text, not JSON. Keep the API key secret; request a new one from DSWMS if it may have been exposed.

Enabled interfaces

Each interface is enabled per client during onboarding. A request to an interface that is not enabled for your client is rejected with 400 Bad Request:

{
    "success": false,
    "message": "Interface 'ARTICLES' is inactive for your client",
    "errors": null,
    "data": null
}

Requests

• Request bodies are JSON and must be sent as UTF-8 with Content-Type: application/json.
• The top-level request body is a JSON array for the article interfaces (Articles, Article Split Groups, Article Units, Article Unit Barcodes, Article Empties) and a JSON object for the others (Customer, Purchase Orders, Customer Orders, Inventory Request). Each interface page shows the expected structure.
• Field names are snake_case, exactly as listed on each page.
• Fields that are not documented are ignored.
• A body that is not valid JSON, or that does not match the expected structure (for example an object where an array is expected), is rejected with 400 Bad Request and the message The request is empty.

Identifiers

Unless stated otherwise, identifiers are the ERP's own identifiers ("external IDs"), for example article_id, id of a customer, or the external ID of a purchase or customer order. Records are created if the identifier is not yet known to DSWMS and updated if it is.

Records referenced by a request, such as the articles of an order line, must already exist in DSWMS. Requests that reference unknown identifiers are rejected, as described on each page.

Data types

Type	Format	Example
date	yyyy-MM-dd string, used in paths	2026-09-17
date-time	yyyy-MM-dd'T'HH:mm:ss string, no time zone	"2026-09-17T14:30:00"
number	JSON number, decimals allowed	12.250
boolean	true or false	true

Where a request field accepts a date-time, it also accepts a Unix epoch timestamp in seconds (10 digits) or milliseconds, sent as a string of digits. The interface pages list which fields accept this.

Date-times in responses are expressed in the time zone configured for your client and carry no time zone suffix.

Responses

Response envelope

Every endpoint returns a JSON envelope:

Name	Type	Description
success	boolean	true if the request was processed, false if it failed
message	string or null	Reason of the failure; null on success
errors	array or null	Per-record errors, returned by interfaces that process records independently; otherwise null
data	any or null	Response payload, if the endpoint returns one; otherwise null

{
    "success": true,
    "message": null,
    "errors": null,
    "data": null
}

The exceptions are successful Purchase Order Receives and Customer Order Delivery requests, which return the requested document directly, with its own success and message fields. Each interface page shows its response.

The message text is meant for logs and troubleshooting. Its wording may change, so do not parse it.

HTTP status codes

Status	Meaning
200 OK	The request was processed successfully.
400 Bad Request	The request was not processed, or was processed only partially. The envelope has "success": false and a message, and errors where the interface reports failures per record.
401 Unauthorized	Credentials are missing or invalid. Plain-text body.
415 Unsupported Media Type	A POST request was not sent with Content-Type: application/json.

An unexpected failure while processing a request is reported as 400 Bad Request with the message Unexpected error. Network errors and 5xx responses from the hosting infrastructure are possible as with any HTTP service; retry them with a back-off.

Partial processing

Requests are processed synchronously: when the response arrives, the data has been saved or rejected.

• Purchase orders, customer orders, customers and inventory requests are processed as a whole document. If the document is rejected, nothing from it is saved.
• Article interfaces process each article independently. If some articles fail, the others are still saved, and the response is 400 Bad Request with an errors array that lists the failed articles. Only the failed records need to be sent again.

Master data, purchase orders and customer orders are created or updated by their identifiers, so resending such a request after a failure is safe.