Skip to main content
Der öffentliche Vertrag dokumentiert genau eine produktive Basis-URL:
Interne Entwicklungs- oder Stage-Hosts sind nicht Bestandteil des kundenorientierten Vertrags und dürfen nicht in öffentliche Client-Konfigurationen eingebettet werden.

​
Dry Run im Vergleich zu einer separaten Umgebung

dryRun=true ist ein Request-Modus für unterstützte Schreiboperationen. Er ist keine Sandbox und verwendet keine getrennte Datenbank.

​
Sichere Teststrategie

1

Dedizierten Key verwenden

Erstellen Sie einen Key mit dem kleinstmöglichen Unternehmens- und Divisionsscope, der für Entwicklung oder Abnahmetests erforderlich ist.
2

Abgestimmte Testdatensätze verwenden

Stimmen Sie Testmitarbeiter, Bestellungen, Vorfälle, Divisionen und Payroll-Zeiträume mit den verantwortlichen Kundenadministratoren ab.
3

Schreibvorgänge zuerst validieren

Verwenden Sie dryRun=true bei unterstützten Operationen und prüfen Sie die projizierte Ressource sowie das Fehlerverhalten.
4

Kontrollierten Schreibvorgang ausführen

Führen Sie im abgestimmten Scope genau eine reale Anfrage aus und prüfen Sie Speicherung und sämtliche Side Effects.
5

Wiederherstellung testen

Testen Sie Timeouts, 409, 422, 429 und die Deaktivierung von Zugangsdaten, bevor Sie die Automatisierung aktivieren.

​
Was der Health-Endpoint bestätigt und was nicht

GET /health bestätigt, dass die Public API erreichbar ist und ihre Health-Antwort zurückgeben kann. Der Endpoint bestätigt nicht:
  • die Gültigkeit des API-Keys
  • den Tenant- oder Divisionsscope
  • den Zugriff auf eine konkrete Ressource
  • die Verfügbarkeit einer nachgelagerten Dokumentdatei
  • die Korrektheit eines Write-Payloads
Verwenden Sie mindestens einen geschützten Read und einen unterstützten Dry Run für eine End-to-End-Prüfung der Integration.
Verwenden Sie keinen undokumentierten internen Host als Fallback. Ein Client muss sicher fehlschlagen, wenn die produktive Basis-URL nicht verfügbar ist.
Zuletzt geändert am 27. August 2026