Limits & Kontingente
Diese Seite fasst alle Zahlen an einem Ort zusammen: Rate Limits, Größenbegrenzungen, Aufbewahrungsfristen. Damit Sie nicht fünf Dokumente lesen müssen, wenn Sie wissen wollen, wie groß ein Webhook-Payload sein darf.
Rate Limits
| Aktion | Limit | Fenster | Gilt pro |
|---|---|---|---|
| Login-Versuche | 5 | 1 Minute | IP-Adresse |
Generischer API-Inbound (POST /api/v1/inbound) |
100 | 1 Minute | API-Key |
Generische API-Abfragen (GET /api/v1/messages/{id} u. a.) |
1 000 | 1 Minute | API-Key |
Webhook-Inbound (POST /api/v1/webhook/{token}) |
100 | 1 Minute | Pipeline |
| Verbindungstest (Transport) | 5 | 1 Minute | Transport |
| KI-Mapping-Vorschläge | 10 | 1 Minute | Mandant |
| KI-Mapping-Chat | 20 | 1 Minute | Mandant |
Wird ein Limit überschritten: HTTP 429 Too Many Requests mit Header Retry-After.
Payload-Größe
- Maximal 5 MB pro Request (raw body)
- Wird sowohl am Webserver als auch in der Applikation durchgesetzt – große Requests werden abgewiesen, bevor der Body vollständig gelesen wird
- Größere Payloads → HTTP 413 Payload Too Large
Gilt für alle Inbound-Endpoints (webhook/{token}, cxml/{token}, inbound).
Content-Type-Vorgaben
| Endpoint | Akzeptierte Content-Types |
|---|---|
POST /api/v1/webhook/{token} |
application/xml, text/xml, application/json, application/edifact, text/plain |
POST /api/v1/cxml/{token} |
application/xml, text/xml |
POST /api/v1/inbound |
application/xml, text/xml |
Passt der Content-Type nicht → HTTP 406 Not Acceptable.
Timeouts
- HTTP-Transport: 10 s Connect-Timeout, 30 s Gesamt-Timeout (pro Request). REST-API-Transport lässt beide Werte überschreiben.
- Verbindungstest: 10 s Gesamt-Timeout
- Inbound-HTTP-Request: 120 s für den synchronen Teil (Authentifizierung, Queue-Einreihung, Antwort an Absender). Die eigentliche Transformation und Zustellung läuft danach asynchron.
Bei FTP/SFTP-Transport sind Timeouts protokollspezifisch und liegen in der Größenordnung von 30 Sekunden pro Einzelschritt (Verbindung, Upload, Rename).
Pipelines und Transporte pro Pipeline
- Pipelines pro Mandant: abhängig vom Abo (Basis + Addon
additional_pipelinesmit Mengenangabe) - Transporte pro Pipeline: keine harte Grenze; praktisch 1–5 üblich (Primär + Fallback)
- Credentials pro Pipeline: keine harte Grenze; praktisch 1 pro Partner
Aufbewahrung
| Daten | Aufbewahrung | Cleanup-Methode |
|---|---|---|
| Raw Payloads (eingegangen) | 90 Tage | Automatischer täglicher Cleanup-Lauf |
| Transformierte Payloads | 90 Tage | Gleich |
| Bestellungs-Datensatz (ohne Payloads) | unbegrenzt | Wird nicht gelöscht, nur Payloads geleert |
| Transport-Logs | 90 Tage | Gleich mit Cleanup-Lauf |
| Audit-Log-Einträge | 365 Tage | Automatischer täglicher Cleanup-Lauf |
| Benutzer-Sessions | Max. 480 Min Inaktivität + 30 Tage "Remember" | Automatische Garbage-Collection |
Längere Aufbewahrungsfristen sind auf Anfrage möglich.
Retry- und Job-Limits
- Retry-Versuche pro Nachricht: max. 5
- Retry-Backoff: 1 min / 5 min / 30 min / 2 h / 24 h
- Gleichzeitige Hintergrund-Jobs pro Mandant: kein hartes Limit. Fair-Share durch Queue-Priorisierung stellt sicher, dass kein einzelner Mandant die Verarbeitung anderer blockiert.
API-Key-Limits
- API-Keys pro Mandant: keine harte Grenze; praktisch 1–3 üblich
- Key-Rotation: API-Keys können jederzeit widerrufen werden. Neue Keys werden einmalig als Klartext angezeigt.
Passwort-Regeln
- Mindestlänge: 12 Zeichen
- Komplexität: Mindestens Groß- und Kleinbuchstaben sowie Zahlen
- Hashing: moderner, salted Passwort-Hash. Klartext-Passwörter werden nie gespeichert.
Session-Timeout
Konfigurierbar pro Mandant: 30 / 60 / 120 / 480 Minuten. Default 120. Details: Sicherheit.
Technische Details
Retry-After-Header
Bei 429-Antworten sendet Orderport einen Retry-After-Header mit Sekunden bis zum nächsten möglichen Versuch. Gut erzogene HTTP-Clients (inklusive Shopify und Orderports eigener Retry-Worker) respektieren das.
Payload-Grenze
Das 5-MB-Limit wird mehrschichtig durchgesetzt: am Webserver und in der Applikation. Grössere Requests werden mit HTTP 413 abgewiesen, bevor das Body überhaupt vollständig gelesen wird.
Cleanup
Die Payload- und Audit-Log-Bereinigungen laufen täglich als geplante Hintergrund-Aufgabe. Sie können nicht manuell ausgelöst werden – der Zeitpunkt des Cleanups ist nicht garantiert minutengenau, aber täglich sicher.