Zum Hauptinhalt springen

Onboarding-Checkliste

Um den Integrationsprozess zu beschleunigen, nutzen wir diese zentrale Checkliste für Onboarding und technischen API-Abgleich.

⬇️ Checkliste als .md herunterladen
Tipp zur Bearbeitung

Sie können die heruntergeladene Datei direkt kopieren, intern ausfüllen und bei Bedarf pro Punkt einen Status ergänzen, z. B. ([Owner], [Datum], [Kommentar]).

Branding & Assets​

Für die Darstellung in den Partner-Apps benötigen wir Ihr Logo in verschiedenen Formaten:

Logo-Anforderungen
  • Format: Bevorzugt als SVG (für verlustfreie Skalierung), oder andere gängige Bildformate.
  • Varianten: Eine Version für helle Hintergründe und (falls vorhanden) eine für dunkle Hintergründe (Dark Mode).
  • Layout:
    • Lange Version: Kompletter Markenname mit Logo.
    • Quadratische Version: Reduziertes Icon/Signet (z.B. für Favicons oder kleine Ansichten).

Technische Ressourcen​

Je nach Integrationsszenario benötigen wir unterschiedliche Unterlagen:

  • Szenario A (Bestehende API):
    • Spezifikationen: OpenAPI/Swagger-Dateien, Postman-Collections oder detaillierte Dokumentation.
    • Auth-Details: URLs für Auth-Server, Token-Endpunkte, Client-IDs/Secrets (OAuth2) oder Authentifizierungs-Schemata.
  • Szenario B (Neue API auf Basis der brokerize-Standardspezifikation):
    • Entwicklungsplan: Kurze Info, welche Teile der mit uns abgestimmten Standardspezifikation umgesetzt werden.
    • Abweichungen: Dokumentation von Feldern oder Endpunkten, die bewusst anders implementiert werden.

API-Mapping & Feature-Support​

In diesem Abschnitt prüfen wir gemeinsam den funktionalen und technischen Fit Ihrer API mit dem brokerize-Interface.

Authentifizierung & Session-TAN​

  • Session-TAN: Unterstützt Ihre API das Session-TAN-Verfahren? Ist eine TAN für jede Depot-Aktion (z.B. Orderaufgabe) erforderlich oder wird eine Sitzung für einen gewissen Zeitraum freigeschaltet?
  • Alternative Methoden: Welche anderen Methoden zur Freigabe werden unterstützt (z.B. App-Freigabe/Push-Verfahren)?

Datenabfrage & Performance​

  • Paginierung: Werden große Listen (Order-Historien, Positionslisten) paginiert zurückgegeben?
  • Datumsfilter: Können Order-Daten gezielt nach Zeiträumen gefiltert werden?
  • Historische Tiefe: Wie weit in die Vergangenheit ist die Order-Historie über die API abrufbar?
  • API-Besonderheiten: Gibt es technische Einschränkungen oder Besonderheiten (z.B. keine parallelen Requests möglich, strikte Rate-Limits, sequentielle Verarbeitung)?

Order-Funktionalitäten​

  • Order-Modelle: Welche Typen werden unterstützt? (Market, Limit, Stop, Stop-Limit etc.).
  • Änderungen & Streichungen: Können bestehende Orders geändert werden (ChangeOrder) oder ist nur eine Streichung und Neuanlage möglich?
  • Gültigkeit: Welche validityTypes stehen zur Verfügung (tagesgültig, Gültig bis Widerruf, etc.)?
  • Teilausführungen: Sind Teilausführungen von Aufträgen möglich? Falls ja, über welchen Endpunkt werden diese Informationen bereitgestellt?
  • Bruchstückhandel: Ist der Handel von Bruchstücken (Fractional Shares) möglich? Gibt es hierbei Einschränkungen (z.B. nur an bestimmten Handelsplätzen)?

Datenformate & Standards​

  • Zeitstempel: Wir können mit verschiedenen Datumsformaten umgehen. Es ist jedoch hilfreich zu wissen, ob Ihre API Zeitstempel einheitlich ausgibt. Wir bevorzugen das ISO 8601-Format (z.B. 2023-10-27T10:00:00Z), idealerweise in UTC.
  • Währungen & Performance: Beträge (Kurse, Gebühren, Steuern) müssen immer zusammen mit der entsprechenden Währung (ISO 4217, z.B. EUR, USD) angegeben werden. Für eine optimale Performance-Darstellung ist es ideal, wenn alle Performancedaten (soweit möglich) in der Portfolio- bzw. Kontowährung geliefert werden.
  • Zahlenformate: Wir bevorzugen numerische Werte als Strings oder Dezimal-Typen, um Rundungsfehler bei Fließkommazahlen (Floats) zu vermeiden.

Fehlerbehandlung & Statuscodes​

  • HTTP-Statuscodes: Konsistente Nutzung (z.B. 400 für Validierungsfehler, 401 für abgelaufene Sitzungen, 422 für Geschäftslogik-Fehler).
  • Fehlermeldungen: Wie funktioniert das Error-Handling auf Broker-Seite?
    • Gibt es detaillierte Informationen in den API-Responses?
    • Liefert die API bereits übersetzte Texte für Fehlermeldungen, die direkt an den User weitergeleitet werden können?
    • Falls keine übersetzten Texte geliefert werden: Können Sie uns eine Liste der Fehlercodes mit entsprechenden Textvorschlägen zur Verfügung stellen?

Erweiterte Features​

  • Spezial-Assets: Unterstützung von Crypto-Handel oder Fremdwährungskonten.
  • Zusatzinfos: Werden Ordergebühren und Steuern ausgewiesen?

Testzugang​

Für die Entwicklung und Qualitätssicherung ist mindestens ein Testaccount in der Sandbox-Umgebung erforderlich. Optimal wäre die Bereitstellung mehrerer Accounts, um verschiedene Szenarien abzudecken:

  1. Normaler Account: Standard-Depot mit (virtuellen) Beständen und Cash.
  2. Fremdwährungskonto: Ein Account mit Konten in verschiedenen Währungen (z.B. USD, CHF), um das FX-Handling zu validieren.
  3. Spezial-Konfiguration: Accounts, die präpariert sind, um Risikohinweise, Zielmarkt-Überprüfungen oder die Termingeschäftsfähigkeit zu testen.

Konfigurationsdaten (für beide Szenarien)​

  • Exchange Map: Falls Sie mehrere Handelsplätze unterstützen, benötigen wir eine Liste mit IDs, Short-Codes und den entsprechenden Anzeigenamen. Eine statische Liste oder Endpunkte über die wir uns die Daten ziehen können sind beide in Ordnung.
  • Compliance: Eventuelle Risikohinweistexte, die Nutzern vor dem Handel mit speziellen Instrumenten (z.B. Hebelprodukte, Crypto) angezeigt werden müssen.
  • Lagerstellen: Wie geht Ihre API mit verschiedenen Lagerstellen um? Falls Lagerstellen über IDs oder Kürzel identifiziert werden, benötigen wir eine Zuordnung dieser Werte zu lesbaren Bezeichnungen für den Endnutzer.

Nächster Schritt​

Wenn die Checkliste initial ausgefüllt und abgeschickt ist, prüfen wir sie auf unserer Seite und machen einen Termin zur Abstimmung und zum weiteren Vorgehen aus.