githubEdit

Carrier management

A carrier is an external shipping provider (for example, DHL, FedEx, UPS) responsible for transporting packages across the supply change. Each carrier offers distinct services, coverage areas, and service levels.

Carrier management allows the simultaneous connection of different shipping service providers and offers various shipping options at different facilities.

It's primarily used in combination with the order fulfillment but can also be operated headless.

circle-check

Role in fulfillmenttools

Carrier data (for example, pickup availability, cutoff times, service options) is used during routing to compute a shipment carrier recommendation per order. If a carrier is specified at order level, that specification is used. If not, the recommended carrier is applied during shipment creation based on configured availability and operational constraints.

Functional capabilities

Carrier integrations enable:

  • Shipment carrier recommendation based on routing decisions. Applied during shipment creation if no carrier is specified at order level.

  • Creation of shipping and return labels.

  • Access to tracking information.

  • Automatic update of the handover task upon parcel pickup.

  • Recording and processing of delivery events, including successful delivery and delivery issues.

Carrier configurations

For consideration during routing and shipment, carriers must:

  • Be activated at tenant level (credentials and core settings).

  • Be connected to facilities (facility-carrier connection with status, cutoff times, and optional delivery areas).

  • Include Carrier Country Service Mappings (CCSMs) for source and destination requirements and allowed services.

  • Define label or parcel classifications and non-delivery days (optional).

  • Set carrier capacity per facility-carrier pickup slot (optional).

Available carriers

Carrier integrations facilitate data exchange with external shipping providers, enabling label creation, tracking, delivery event processing (for example, pick up, in transit, delivered), and handover updates.

Two integration models are supported that are connecting fulfillmenttools and carriers:

  • Direct integration: A connection to the carrier's native technical interface. You'll find a list available in the Standard carrier integrations section.

  • Third-party integration: A connection via a multi-carrier provider that acts as an intermediary and offers access to multiple carriers through a single interface. You can find more information in either the Custom carriers section below and full details in the Custom carrier article.

Both models support the same functional scope and are accessed through a consistent API layer. The integration method can differ per tenant, depending on contractual and operational requirements. Direct and third-party integrations can also be combined in parallel if needed.

Standard carrier integrations

The following carriers are currently have direct integrations with fulfillmenttools. Availability depends on the region and service coverage defined in contractual agreements.

Carrier
Release state
Key
Notes
GA

BRING

Norway (domestic)

GA

DHL_V2

Domestic shipping in Germany

GA

DHL_BENELUX

Belgium, Netherlands, Luxembourg (domestic)

GA

DHL_EXPRESS

International

ALPHA

DPD

Germany

DPDarrow-up-right (Switzerland)

ALPHA

DPD_CH

Switzerland

GA

GLS

Germany (domestic)

GA

INTEX

Germany (domestic)

GA

POSTNL

Netherlands (domestic)

GA

POST_NORD

Scandinavia

UPS via Parcelbroker

ALPHA

UPS_PARCELBROKER

Germany

Technology partners Some carriers are integrated through technology partners (for example, VCE). In these cases, the type of credentials required may differ from the carrier's native API. Credentials are provided as part of the onboarding process.

circle-exclamation

Custom carriers

If you don't want to use one of our native carrier integrations, you can create a custom carrier that's connected through an external service or operational process. This mechanism enables you to integrate:

  • Local delivery partners (for example, bike couriers)

  • Store operators who hand parcels to local drop-off points at flexible times

  • Internal delivery fleets with independent routing systems and apps

See the Custom carrier article for more information.

Carrier connections to facilities

Carriers must be explicitly connected to facilities to be available during shipment creation and routing. A facility-to-carrier connection defines where a carrier is operationally available and specifies the configuration parameters that influence routing and shipping logic.

Entities in carrier integration

Carrier integration involves two categories of entities:

Configurations entities

Define how carriers can be set up and used.

Operational entities

Represent objects created during the fulfillment process:

  • Shipment: A container for one or more parcels, always linked to a carrier

  • Parcel: A single physical parcel with its own label and tracking information

  • Delivery events: Status updates such as pickup, in-transit, or delivered

Facility-to-carrier configuration parameters

Each facility-to-carrier connection contains specific parameters:

  • Cut off time: Time when the carrier performs parcel pickup at the facility. Affects same day delivery eligibility and must align with the facility's fulfillment schedule

  • Delivery areas (optional): Postal codes and country codes defining where shipments can be delivered from this facility

  • Carrier status: Only carriers that are active both at network and facility level are available for routing

  • Capacity limits and non-delivery days (optional): Rules to ensure that pickup constraints and calendar restrictions are respected

  • Versioning and URL overrides: Updates require versioning (optimistic locking). Facility-specific URL overrides can be defined to differentiate between sandbox and production usage

All configuration steps related to carrier activation and facility assignment must be performed via API. Once activated, carriers can be further managed in Backoffice.

Example of different facilities with individual facility–carrier connections, including standard, same day, custom, and bike carriers.

circle-check

Data for activating carriers

To ensure frictionless shipping operations, certain data must be available at shipment creation. Data is categorized as mandatory, recommended, or optional. While only mandatory data is required for domestic shipments, providing both mandatory and recommended data is strongly advised, especially for international use cases.

Data type
Mandatory data
Recommended data
Overwrite rule

Source (facility) data

Postal address of the shipping facility

  • Telephone number

  • Email address

parcel.sender ▷ shipment.sourceAddress ▷ facility.address

Target (consumer) data

Consumer postal address (including house number)

  • Telephone number

  • Email address

parcel.recipient ▷ shipment.targetAddress ▷ order.consumer.address

Customs (international shipments)

None

  • HS Code (8 digits)

  • Customs value per unit (in minor currency units, for example, cents)

  • Currency (ISO-4217)

  • Number of decimal places

orderLine.article.attributes ▷ listing.attributes

Insurance values

None

  • Insurance value per unit (minor currency units)

  • Currency (ISO-4217)

  • Number of decimal places

Customs and insurance data are handled separately, no fallback between categories

Physical dimensions and weight

None

Weight per unit (grams) Height, width, length (mm) (optional)

orderLine.article.attributes ▷ listing.attributes

Parcel label classifications

  • Array of predefined parcel types (dimensions, weight) selectable during label creation

  • Values are carrier- and contract-specific and may be omitted

  • Duplicates are prohibited: Two entries are duplicates if their dimensions and services are identical

Adding a carrier

In this section, we'll demonstrate how to configure carriers and connect them to facilities via the API.

1

Add the carrier

Send a request to the endpoint to create a carrier. In this example, we'll create a DHL carrier and assume the default parcel weight is 2kgs.

2

Connect the carrier to a facility

A connection is established with a POST request to the endpoint for facility-carrier connectionsarrow-up-right. ad.

For a basic connection, an empty JSON object is sufficient for the payload.

This request requires the id of the previously created carrier and the id of the target facility.

You can provide a lot more details in your request, see the example below or the carrier endpoints article.

chevron-rightMore details request for carrier creationhashtag
3

Set the connection to active

Send a PUT request to the same endpoint and use a request with an active status.

This process can be repeated for all required facility-carrier connections.

To get a list of the available carriers, use the below endpoint. For a more detailed view, you can use the specific carrier endpoint.

Parcels and shipments

A parcel is the digital representation of one physical parcel that's on its way to the consumer. A shipment is the bracket around all parcels sent within a process using the same carrier.

After a parcel was created in status OPEN, fulfillmenttools is automatically taking care of the actual creation of the parcel label. During the time it takes fulfillmenttools and the CEPs API to negotiate and create a parcel, the status of the parcel changes from OPEN via PROCESSING to finally DONE. The shipment also changes its status to CONFIRMED as soon as all created parcels of the shipment have reached the status DONE.

If a special service (for example, a signature) is required, this can be configured either when creating the parcel or the order. Only services offered by the chosen carrier will be taken when creating a parcel. Providing a service for a carrier which doesn't offer that service will be ignored.

Relationship between shipments and parcels.

Each parcel belongs to exactly one shipment. A shipment reaches CONFIRMED when at least one parcel is DONE and no parcel remains in OPEN or WAITING_FOR_INPUT.

Process overview

After the order is captured, routing is triggered. The resulting routing plan event includes the carrier, either taken from the order or preselected as the best available carrier according to configuration (carrier shipment assignment). From this event, the shipment and pick job are created. At this moment, the carrier is set on the shipment (shipment creation).

When using clients, picking and packing are completed so that the subsequent label request contains the actually picked/packed items. In headless scenarios, a label can be requested immediately (process-dependent), or items can be provided explicitly with the request (parcel creation). The label request is asynchronous. Parcels progress through OPEN to PROCESSING to DONE/FAILED, and the shipment follows the defined status logic.

Shipment status flow

  • INITIAL: Shipment created

  • REQUEST: Parcel label requests initiated

  • CONFIRMED: All parcel labels have been successfully created

  • COMPLETED: Shipment processed

Parcel status flow

Label creation is performed asynchronously via the carrier API. While communication is in progress, the parcel remains in PROCESSING. The status progresses as follows:

  • OPEN: Parcel created

  • PROCESSING: Label request submitted; awaiting carrier/CEP response

  • WAITING_FOR_INPUT: Parcel created but required information is missing (for example, per CCSM)

  • DONE: Label creation completed

  • FAILED: Label creation was not successful

Upon completion, the parcel result includes tracking information and label download links. On failure, the summary contains carrier error details.

Create a shipment for a parcel

1

Create a shipment

Use the endpoint below with the request to create a shipment.

2

Create a parcel

Use the endpoint below with the request to create a parcel associated with the shipment.

circle-info

This example shows the simplest way to create a parcel, where fulfillmenttools uses all necessary information from the corresponding shipment. However, it's possible to override data from the shipment for each created parcel, such as its dimensions, recipient, sender, or return address.

This creates the parcel entity with the status OPEN. Asynchronously, fulfillmenttools automatically advises the parcel label with the carrier. During this process, the parcel status transitions from OPEN to PROCESSING, and finally to DONE. The shipment status changes to CONFIRMED once all its associated parcels reach the DONE status.

3

Get updates on the parcel status and check results

Once the parcel status is DONE (successful) or FAILED, the result attribute contains the outcome.

Last updated