DACHSER

Carrier-specific setup for DACHSER in Shipping Labels.

Purpose

This page describes the DACHSER-specific setup in Shipping Labels. It covers the reference lists for products, branches, and package types as well as the API keys, endpoints, divisions, depot selection, and fallback package properties required for productive label requests.

Prerequisites

  • The shared Shipping Labels setup is complete.
  • DACHSER test and productive endpoints are available.
  • The required API keys for the relevant environment are available.
  • Products, branches, and package types are known from the DACHSER onboarding material.
  1. Maintain the DACHSER product list.
  2. Maintain the DACHSER branch list and package types.
  3. Assign test or productive endpoint and API key.
  4. Select division, depot, product, label count, and fallback package properties.
  5. Validate the setup first in test mode and switch to productive mode only for go-live.

Setup components

Build the DACHSER reference lists first

DACHSER is not only a credential setup. Before the main line becomes usable, you should maintain the supporting lists for products, branches, and package types.

These lists provide the business values later selected in the final setup:

  • products with DACHSER division and product identity
  • branches with branch number, organization, and city
  • package types with code and description

For the branch list, use only the values published by DACHSER. The branch number is an eight-digit numeric value and typically starts with leading zeros. Organization and city belong unchanged to that depot record. When you import CSV data, verify the column order and cell format carefully; multiline cells or an unintended replacement of existing entries can disturb the current setup.

Complete API access and endpoint assignment

Maintain the DACHSER API key together with the matching test or productive URL. Treat this as environment-specific setup and avoid mixing sandbox and live data on one line.

If productive mode is enabled too early, requests may be sent against the live integration before the business values were fully validated.

Select division, depot, and operational properties carefully

The main DACHSER setup includes the values that control how the request is interpreted:

  • division such as transport or food logistics
  • depot or forwarder selection
  • product selection
  • number of labels
  • fallback package dimensions and weight

These business fields should only be chosen from the validated reference data, not by approximation.

The division represents DACHSER’s internal business areas such as transport or food logistics. The depot or forwarder is also not free text but a branch value defined by DACHSER. Although that depot is not printed on the label, it is still mandatory for the internal processing of the request.

Keep branch numbers and package data consistent

Branch handling is especially sensitive in DACHSER. Branch numbers can contain leading zeros and should be stored exactly as provided. In addition, package data must still be available either through item attributes or through the DACHSER fallback properties.

If item attributes for length, width, height, and weight are already maintained, at least the matching package type still needs to be set completely in practice. If no item attributes are available, maintain the fallback properties fully on the DACHSER setup. If both sources are missing, the request will fail.

Process Important DACHSER notes These points reduce avoidable DACHSER onboarding and request issues.
  • Keep leading zeros in branch numbers.
  • Treat branch import carefully because replacing entries can affect existing setups.
  • Use carrier-provided products and package types without renaming them semantically.
  • Keep productive mode disabled until the DACHSER test scenario is validated.
  • Provide dimensions and weight either through item attributes or the DACHSER setup properties.

Links

Further Information

Related content