SendLabel x Lingxing

Lingxing ERP / WMS API Integration Guide

This page is ready to share directly with the Lingxing technical team. It focuses on test accounts, API path selection, validation flow, and production safety boundaries.

Contact details

SendLabel.de

https://www.sendlabel.de

info@sendlabel.de

+49 151 4581 6823

Depha GmbH, Steinriedendamm 15, Halle 1, Eingang 1, 38108 Braunschweig, Deutschland

Exported at: 07/08/2026, 06:27

Back to help center Open API docs Open API test page Open print view

What You Will Receive

Our admin will create or reuse a dedicated frontend account for Lingxing and generate a test API key.

The package usually includes the login email, initial password for new accounts, test token / client_secret, recommended client_id, and the enabled channels.

- The account is test-only by default and does not include production access.

- Real shipment creation requires per-account production enablement by our team.

- Use validate_only / dry_run first to validate auth, address handling, and field mapping before requesting production.

Boundary Between the Test Account and Customer Production Accounts

The account and token provided here are primarily for platform-level integration testing so the Lingxing and SendLabel teams can complete the technical validation first.

When real merchants later use SendLabel inside Lingxing, they should not keep using this shared test account or a single Lingxing-wide production credential long term.

- Each real customer should first register or sign in on the SendLabel website and submit their own API access request.

- After approval, our team enables production for that specific customer account and creates a customer-specific production API key.

- The customer then places their own production key into Lingxing so orders, billing, risk controls, audit trails, and cancellation rights stay tied to that customer account.

Recommended Validation Flow

This is the safest validation path and avoids billing mismatches, charges, or leftover live labels.

- Step 1: verify authentication and confirm the request reaches the intended channel.

- Step 2: use validate_only to check address structure, required fields, and basic business validation.

- Step 3: use dry_run to inspect expected pricing and possible error branches without creating a real shipment.

- Step 4: if production validation is required, our team enables it per account and recommends pairing it with auto-revoke.

Authentication

We recommend `Authorization: Bearer <API_KEY>`. If the current client is closer to a native UPS / DHL implementation, compatible headers and client_id aliases are also supported.

- `Authorization: Bearer <API_KEY>`

- X-API-Key / X-SendLabel-API-Key

- Basic(base64(prefix:key))

- dhl_<API_KEY_PREFIX> / ups_<API_KEY_PREFIX> client_id aliases

Common Entry Points

New systems should start with the unified API. Existing native UPS / DHL clients can start with compat routes to reduce change volume.

- https://www.sendlabel.de/api/v1/shipments/import

- https://www.sendlabel.de/api/v1/orders/{orderId}

- https://www.sendlabel.de/api/v1/orders/{orderId}/tracking

- https://www.sendlabel.de/api/compat/dhl-parcel-de/v1/shipments/import

- https://www.sendlabel.de/api/compat/ups/v1/shipments/import

- https://www.sendlabel.de/api/compat/ups/security/v1/oauth/token

Test Request Example

The commands below cover unified validate_only and UPS compat dry_run. If these succeed, most field mapping issues are already clarified.

curl -X POST "https://www.sendlabel.de/api/v1/shipments/import" \
  -H "Authorization: Bearer <API_KEY>" \
  -H "X-SendLabel-Execution-Mode: validate_only" \
  -H "Idempotency-Key: lingxing-validate-0001" \
  -H "Content-Type: application/json" \
  -d '{
    "carrier": "DHL_PARCEL_DE",
    "shipments": [
      {
        "reference": "LX-10001",
        "recipient": {
          "name": "Max Mustermann",
          "street1": "Lindenstr. 5",
          "postalCode": "70173",
          "city": "Stuttgart",
          "countryCode": "DE"
        },
        "parcel": { "weightKg": 1.2, "lengthCm": 30, "widthCm": 20, "heightCm": 10 }
      }
    ]
  }'

curl -X POST "https://www.sendlabel.de/api/compat/ups/v1/shipments/import" \
  -H "Authorization: Bearer <API_KEY>" \
  -H "X-SendLabel-Execution-Mode: dry_run" \
  -H "Idempotency-Key: lingxing-ups-dryrun-0001" \
  -H "Content-Type: application/json" \
  -d '{
    "carrier": "UPS",
    "shipments": [
      {
        "reference": "LX-UPS-10001",
        "recipient": {
          "name": "Erika Mustermann",
          "street1": "Lindenstr. 5",
          "postalCode": "70173",
          "city": "Stuttgart",
          "countryCode": "DE"
        },
        "parcel": { "weightKg": 1.5, "lengthCm": 30, "widthCm": 20, "heightCm": 10 }
      }
    ]
  }'

Production Validation and Guardrails

Even if the API key has production scope, the server still blocks live creation when the account-level production switch is off.

For customers that need real shipment validation, we recommend controlled live tests with a configurable auto-revoke delay.

- Test accounts do not include production by default.

- Only dedicated integration test accounts should be eligible for production validation.

- Enable auto-revoke for live test shipments to avoid ongoing charges.

Pre-Integration Checklist

Use this checklist during the technical kickoff before implementation starts.

- Confirm the integration uses a dedicated test account instead of an admin account.

- Confirm whether DHL, UPS, or both channels are required.

- Confirm that requests consistently send `Idempotency-Key`.

- Confirm the client reads the normalized `sendlabelError` first.

- Confirm the production validation plan includes auto-revoke and charge control.