API

Alles, was die Webplattform tut, tut sie über diese API – dahinter gibt es keine private Schnittstelle. Die Kunden-Endpunkte liegen unter /v1, und die Schnittstelle ist versioniert, damit die Plattform unabhängig von dem weiterentwickelt werden kann, was Sie darauf aufbauen.

• JSON in beide Richtungen, durchgängig mit Feldnamen in camelCase.
• Geldbeträge und Kurse sind Dezimal-Strings, niemals Gleitkommazahlen, damit bei der Übertragung kein Wert verloren geht.
• Zeitstempel sind ISO 8601 in UTC mit abschließendem Z.
• Unbekannte Felder in Anfragen werden abgelehnt statt ignoriert, sodass ein Tippfehler sofort auffällt, statt stillschweigend nichts zu bewirken.
• Bei jeder Order und jeder Geldbewegung ist ein Idempotency-Key-Header erforderlich. Eine Wiederholung liefert die gespeicherte Antwort, statt die Aktion zweimal auszuführen.
• Listen verwenden Cursor-Paginierung (limit und cursor). Es gibt keine Offset-Paginierung, da sie bei Daten, die sich während des Lesens ändern, Lücken und Duplikate erzeugen würde.

Jede Antwort hat dieselbe Hülle. Erfolgreiche Aufrufe liefern ein data-Objekt zusammen mit meta, das die Anfragekennung und den nächsten Paginierungs-Cursor enthält. Fehler liefern ein error-Objekt mit einem stabilen, maschinenlesbaren Code, einer lesbaren Meldung und den relevanten Zahlen, damit Ihr Client etwas Konkretes statt eines allgemeinen Fehlers anzeigen kann.

Verzweigen Sie Ihre Logik anhand des Codes, nicht der Meldung: Codes sind Teil des Vertrags, Meldungen können umformuliert werden. Nennen Sie die Anfragekennung, wenn Sie ein Problem melden – so finden wir den genauen Aufruf am schnellsten in unseren Logs.

Anfragen sind je Konto ratenbegrenzt. Eine begrenzte Anfrage wird beantwortet statt verworfen, damit Ihr Client sauber pausieren kann, statt zu raten. Der programmatische Zugriff hat dieselben Berechtigungen wie Ihr Konto: Die API kann nichts, was Ihr Login nicht auch könnte.

Für Zugangsdaten oder Fragen zu Limits für eine bestimmte Last wenden Sie sich an den Support.