# HTTP POST

Der HTTP-POST-Transport ist der einfachste Weg, transformierte Bestellungen an ein Zielsystem zu schicken. Orderport sendet einen einzelnen POST-Request mit der Bestellung im Request-Body – typischerweise als XML. Kein Zusatz-Addon erforderlich.

## Wann HTTP POST wählen?

- Ihr ERP oder Zielsystem hat einen **dedizierten Import-Endpoint**, der XML (z. B. openTrans) entgegennimmt
- Die Zielschnittstelle ist **einfach** (keine aufwändigen Header, keine OAuth-Flows)
- Sie brauchen nur **Basic-Auth** oder gar keine Authentifizierung

Wenn Ihr Ziel JSON erwartet oder komplexere Auth-Mechanismen (OAuth, Bearer Token) nötig sind, ist die [REST API](/docs/rest-api) die bessere Wahl.

## Einrichtung

### Im Pipeline-Wizard oder der Detailansicht

1. Pipeline öffnen → **Transporte → Hinzufügen**
2. Typ: **HTTP POST**
3. **URL** eintragen (z. B. `https://erp.example.com/import/orders`)
4. **Authentifizierung** wählen:
   - **Keine** – ungeschützter Endpoint
   - **Basic Auth** – Benutzername + Passwort (Passwort wird verschlüsselt gespeichert)
5. Speichern
6. **Verbindung testen** – Orderport sendet ein leeres Test-Payload und zeigt den HTTP-Status

Sie können beliebig viele HTTP-Transporte pro Pipeline anlegen. Die Priorität bestimmt, welcher zuerst genutzt wird (siehe unten).

### Priorität und Fallback

Wenn eine Pipeline mehrere Transporte hat, versucht Orderport sie der Reihe nach nach `priority` (0 = primär). Erst wenn der primäre Transport fehlschlägt, versucht Orderport den nächsten. Die Reihenfolge lässt sich per Drag & Drop anpassen.

## Technische Details

### Request

Orderport sendet:

```
POST {URL}
Content-Type: application/xml
Authorization: Basic {base64}        (nur bei Basic-Auth)
Content-Length: …

<?xml version="1.0" encoding="UTF-8"?>
<ORDER>…</ORDER>
```

- **Methode**: immer `POST`
- **Content-Type**: `application/xml` (für XML-Output) oder `application/json` (wenn Ausgabeformat JSON ist)
- **Timeout**: 30 Sekunden Gesamt, 10 Sekunden Connect-Timeout
- **User-Agent**: `Orderport/1.0`

### Erfolgskriterium

Ein Zustell-Versuch gilt als erfolgreich, wenn das Zielsystem einen HTTP-Statuscode **2xx** zurückgibt. Alles andere (3xx, 4xx, 5xx, Timeout, Netzwerk) wertet Orderport als Fehler und reiht den nächsten Transport bzw. einen Retry ein.

### Transport-Log

Jeder Versuch erzeugt einen Eintrag im Transport-Log mit Erfolgs-Status, HTTP-Status des Ziels (oder Netzwerkfehler), Antwortzeit in Millisekunden, Antwort-Body (bis 5 000 Zeichen) und Fehlermeldung.

## Fehlerbehebung

| Symptom | Ursache | Lösung |
|---|---|---|
| Transport-Log zeigt HTTP 415 | Ziel erwartet anderen Content-Type | XML-Output vs. JSON-Output prüfen; ggf. im Ziel-System Content-Type-Handler einstellen |
| Timeout nach 30 Sekunden | Ziel verarbeitet synchron sehr langsam | Ziel-System so bauen, dass der HTTP-Call nur annimmt und verarbeitet asynchron weiter |
| Basic-Auth schlägt fehl | Passwort enthält Sonderzeichen, die beim Verschlüsseln korrumpiert wurden | Passwort neu setzen und prüfen, ob kopiertes Passwort Leerzeichen enthält |
| Mehrfachzustellung bei langsamer Antwort | Ziel antwortet erst nach 31 s, Orderport startet schon Retry | Ziel muss < 30 s antworten oder auf den [REST API](/docs/rest-api)-Transport wechseln und `timeout` erhöhen |

## Nächste Schritte

- [REST API](/docs/rest-api) – mit OAuth, Bearer und längeren Timeouts
- [Zugangsdaten](/docs/credentials)
- [Fehlerbehebung](/docs/fehlerbehebung)