Skip to main content

Step 1 – Auftrag anlegen (Create Order)

Grundidee dieses Schrittes

Ein Auftrag benötigt immer eine Location als Ziel.
Diese Location kann auf unterschiedliche Weise definiert werden – abhängig davon, wie weit die Integration gehen soll und welche Stammdaten bereits im System vorhanden sind.

👉 Der weitere Ablauf im Integrationsguide richtet sich danach, wie die Location angegeben wird.

Entscheidungslogik

Wenn Sie neu mit der Integration starten:
➡️ Beginnen Sie mit Variante A – Location über Adresse anlegen

Wenn Sie bereits mit Locations oder Kundenstammdaten arbeiten:
➡️ Springen Sie direkt zu Variante B – Location referenzieren

Auswahl: Wie wird die Location definiert?

Beim Anlegen eines Auftrags stehen zwei empfohlene Varianten zur Verfügung.

Wert Bedeutung
0 id ist eine bekannte Location-Nummer in DeDeFleet
1 id ist eine bekannte Kundennummer in DeDeFleet
2 Location wird über Adressdaten definiert
3 Location wird über Koordinaten (Latitude/Longitude) definiert
4 id ist eine bekannte Mitarbeiternummer in DeDeFleet

Technische Umsetzung (API)

Endpoint

POST /orders

Vollständige URL

https://ortung.dedefleet.de/data/api/2

Authentifizierung

Für alle API-Aufrufe ist ein gültiger Bearer Token erforderlich, der zuvor im DeDeFleet-Portal erzeugt wurde.

Der Token kann auf zwei Arten übergeben werden.

Variante 1 (empfohlen) – Bearer Token im HTTP-Header

Authorization: Bearer <BEARER_TOKEN>
Accept: application/json
Content-Type: application/json
Beispiel (curl)
curl -X POST "https://ortung.dedefleet.de/data/api/2/orders" \
  -H "Authorization: Bearer <BEARER_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{ ... }'

Variante 2 – Bearer Token als URL-Parameter

?token=<BEARER_TOKEN>
Beispiel
?token=<BEARER_TOKEN>
Beispiel (curl)
curl -X POST "https://ortung.dedefleet.de/data/api/2/orders?token=<BEARER_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{ ... }'

⚠️ Sicherheitshinweis:
Für produktive Integrationen wird die Übergabe des Tokens im HTTP-Header empfohlen, da Tokens in URLs in Logs oder Browser-Historien erscheinen können.

Variante A – Location über Adresse anlegen (empfohlener Einstieg)

➡️ Ideal für den Einstieg und einfache Integrationen

Eigenschaften

  • Location wird vollständig über Adressdaten beschrieben

  • Keine Vorab-Stammdaten erforderlich

  • Schnellster Weg zum ersten erfolgreichen API-Aufruf

Pflichtfelder bei location.type = 2

  • street

  • postal

  • city

  • country

Optional:

  • name

  • latitude

  • longitude

Beispiel: Auftrag mit Adress-Location

{
  "type": 0,
  "order": "ORDER-10001",
  "delivery": "DEL-10001",
  "location": {
    "type": 2,
    "name": "Musterkunde GmbH",
    "street": "Hauptstraße 12",
    "postal": "37154",
    "city": "Northeim",
    "country": "DE"
  }
}

Ergebnis im System

  • ✔ Auftrag wird erstellt

  • ✔ Location wird automatisch angelegt

  • ❌ Auftrag ist unverplant

➡️ Weiter im Guide:
Step 2 – Touren anlegen

Variante B – Bestehende Location referenzieren (Advanced)

➡️ Für fortgeschrittene Integrationen

Eigenschaften

  • Auftrag verweist auf eine bereits existierende Location oder einen Kunden

  • Zentrale Pflege der Stammdaten

  • Vermeidung von Dubletten

Typische location.type Werte

  • 0 – bekannte Location

  • 1 – bekannter Kunde

  • 4 – bekannter Mitarbeiter

Beispiel: Auftrag mit referenzierter Location

{
  "type": 0,
  "order": "ORDER-10002",
  "location": {
    "type": 0,
    "id": "LOC-4711"
  },
  "plannedDeliveryDate": "2026-02-01",
  "workTime": 600
}

Ergebnis im System

  • ✔ Auftrag wird erstellt

  • ✔ Bestehende Stammdaten werden verwendet

  • ❌ Auftrag ist unverplant

Zusammenfassung Step 1

  • ✔ Auftrag wird per API angelegt

  • ✔ Location wird abhängig vom location.type interpretiert

  • ✔ Auftrag ist im System sichtbar

  • ✔ Auftrag ist nicht verplant

  • ✔ Grundlage für die Tourenplanung ist geschaffen

Back to top