ProLoyalty technisch ausprobieren
Beginnen Sie mit Testdaten und einem kurzen Ablauf für Mitglied, Kauf, Einlösung und Rückgabe.
Mit dem richtigen Vertrag beginnen.
Mit klaren Fällen weiterarbeiten.
Den ersten Vorgang durchspielen
Testmandant und berechtigten Zugang klären, synthetisches Mitglied anlegen, Kauf melden und den bestätigten Kontostatus lesen.
Unterstützte Version bestätigen
Das Developer Center führt durch Schnittstellenverträge, Testdaten, typische Fehlerfälle und den Abgleich der Ergebnisse.
Ein kurzer Ablauf.
Die gesamte Wirkungskette.
- 01
Vorbereiten
Testmandant, erlaubte Scopes und freigegebene API-Version bestätigen. Nur synthetische Testdaten verwenden.
- 02
Mitglied
Eine eindeutige externe Referenz anlegen und den tatsächlichen Anlagezustand prüfen.
- 03
Kauf
Ein Ereignis mit stabiler fachlicher ID melden. Entscheidung und Gutschrift getrennt nachvollziehen.
- 04
Einlösung
Guthaben kontrolliert reservieren und die Einlösung nach bestätigtem Ergebnis abschließen.
- 05
Rückgabe
Eine Teilretoure auf den ursprünglichen Kauf beziehen und den korrigierten Bestand prüfen.
Welche Voraussetzungen werden vor dem ersten Aufruf benötigt?
Der bestätigte Zugang nennt Testumgebung, Mandant, unterstützte Version, Rollen und Scopes. Tokens werden über das freigegebene Verfahren bezogen und sicher behandelt. Sandbox und Produktion erhalten getrennte Zugänge; ein Beispieltoken in dieser Website ist keine verwendbare Berechtigung.
Warum beginnt der Test mit Referenzen?
Eine stabile Mitglieds- und Ereignisreferenz ermöglicht den späteren Abgleich. Ohne sie lässt sich bei einem Timeout schwer unterscheiden, ob ein Vorgang neu ausgeführt oder nur sein Ergebnis erneut abgefragt werden muss.
Ein erfolgreicher Aufruf
ist erst der Anfang.
Normalfall Kauf K-001 qualifiziert: +100 Punkte. Einlösung E-001 bestätigt: −30 Punkte. Teilretoure R-001 mit Bezug K-001: −20 Punkte. Erwarteter verfügbarer Bestand: 50 Punkte.
Diese Beispiele führen keine externen Requests aus. Statuscodes und technische Antworten werden mit der freigegebenen Version abgeglichen.
Die richtigen Unterlagen.
Keine ungeprüften Downloads.
OpenAPI und Referenz
Objekte, Routen, Authentifizierung, Felder und Fehlertypen müssen zur unterstützten Version passen. Ein Changelog macht relevante Änderungen sichtbar.
Freigegebene Version anfragenPostman Collection
Eine Collection kann den vereinbarten Testablauf reproduzierbar machen. Umgebungsvariablen und synthetische Daten bleiben von echten Geheimnissen getrennt.
Verfügbarkeit bestätigenSDKs und Bibliotheken
Eine Sprachansicht belegt noch kein gepflegtes SDK. Unterstützte Sprache, Version und Wartungsstatus werden je Bibliothek bestätigt.
Keine pauschale SDK-ZusageWie werden Versionen und Deprecation behandelt?
Die Integration bindet sich an eine unterstützte Version. Eine angekündigte Ablösung nennt betroffene Funktionen und den vorgesehenen Übergang. Pagination, Limits und Datenfeldänderungen gehören in denselben Vertrag. Die tatsächlichen Fristen und Verfahren werden anhand freigegebener Unterlagen bestätigt.
Wie wird die Dokumentation durchsucht?
Die freigegebene Referenz benötigt eine klare Navigation nach Objekt, Aktion und Ereignis sowie Versionsbezug und Changelog. Auf dieser öffentlichen Seite werden mangels verifizierter Spezifikationsdatei keine scheinbaren Downloads oder eine Suche über nicht vorhandene Endpunkte angeboten.
Fehler müssen für
Menschen und Systeme verständlich sein.
| Prüfbereich | Typische Codegruppe | Nachzuweisen |
|---|---|---|
| Zugang / Berechtigung | 401 / 403 | Ungültiger Zugang und unzulässiger Datenbereich werden entsprechend dem Vertrag behandelt. |
| Konflikt / Validierung | 409 / 422 | Dublette, Zustandskonflikt und Feldfehler erhalten unterscheidbare Bedeutung. |
| Begrenzung | 429 | Limits und gegebenenfalls Retry-After werden so dokumentiert, wie sie tatsächlich umgesetzt sind. |
| Temporärer Fehler | 5xx / Timeout | Rückoff, begrenzte Wiederholung und Abgleich eines unklaren Ausgangs sind definiert. |
Die Tabelle benennt typische Testbereiche. Sie ist keine Zusage, dass eine bestimmte ProLoyalty-Version jeden Fall mit genau diesen Codes beantwortet.
Ereignisse verifizieren.
Wiederholungen beherrschen.
Eine Nachricht muss vom richtigen Absender stammen, einem nachvollziehbaren Vorgang entsprechen und bei Wiederholung kontrolliert behandelt werden.
Signaturprüfung und vereinbartes Zeitfenster schützen den Empfang. Ereignis-ID, Reihenfolge und Deduplizierung bestimmen, wie derselbe fachliche Vorgang verarbeitet wird. Retry und Replay benötigen einen beobachtbaren Zustellstatus.
Was gehört zum Signaturbeispiel?
Freigegebene Unterlagen beschreiben das tatsächlich verwendete Verfahren, signierte Felder, Zeitfenster und Schlüsselrotation. Synthetische Beispiele enthalten keine realen Schlüssel. Ein frei erfundener Signaturalgorithmus wäre keine belastbare Implementierungsanleitung.
Was wird nach einer Unterbrechung geprüft?
Der Betrieb gleicht offene Nachrichten, bereits bestätigte Wirkungen und externe Referenzen ab. Eine Nachholung darf nicht nur die Zustellung, sondern muss auch die fachliche Einmaligkeit berücksichtigen. Monitoring zeigt Rückstau und wiederholt fehlschlagende Fälle.
Hier geht Ihr Thema weiter.
Ihr Vorhaben. Unser gemeinsamer nächster Schritt.
Besprechen wir Ihre Zielgruppe, Ihre Datenquellen und den Ablauf, den Sie verbessern möchten. Daraus entsteht eine Demo, die zu Ihrem Programm passt.
Ihre Demo beginnt mit Ihrem Alltag.
Ein normaler Vorgang. Ein Sonderfall. Die beteiligten Systeme. Wir zeigen, wie Regeln, Kanäle und Kontrolle zusammenspielen.