# 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_pipelines` mit 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](/docs/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.

## Nächste Schritte

- [Fehlerbehebung](/docs/fehlerbehebung)
- [Audit-Log](/docs/audit-log)
- [Eingangsnachrichten](/docs/inbound-messages)