Hilfe
abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du: 

NEU: comdirect REST API für Privatkunden

SMT_Chris
Community Manager
Community Manager
3.559 Beiträge

Hallo liebe Community,

es ist soweit: wir stellen ab sofort allen unseren Kunden das comdirect REST API zur Verfügung.

 

Was heißt das für euch?

Als Kunden von comdirect habt ihr die Möglichkeit, mit euren eigenen Software-Anwendungen

 

  • Wertpapierorders an börslichen/außerbörslichen Handelsplätzen zu platzieren
  • alle eure Kontosalden, Konto- und Depotumsätze sowie das Orderbuch abzurufen.

Weitere Informationen findet ihr unter developer.comdirect.de. Die Registrierung zur Nutzung des comdirect REST API ist dort ebenfalls verlinkt.

 

Fragen zur Integration des APIs in eure Software könnt ihr gerne hier diskutieren.

 

Viel Spaß beim Ausprobieren wünscht das comdirect API Team!

299 ANTWORTEN

FSQuant
Experte ★
169 Beiträge

Warum nutzt du keine Wrapper-Class, die du primär auf Basis der Postman Doku erstellst?

Das ganze manuelle Rumgefriemel mit den einzelnen URL Parametern ist unglaublich fehleranfällig - meine dringenste Empfehlung an alle ist, dies durch einen strukturierten Wrapper umzusetzen.

 

 

 

MichaM21
Autor ★
4 Beiträge

Hallo zusammen,

ich erhalte beim Abruf meiner Depotliste über die comdirect REST API einen HTTP-Status 403 Forbidden.

Die Authentifizierung läuft vollständig erfolgreich mit der offiziellen Postman-Collection:

  • OAuth Resource Owner Password Credentials Flow erfolgreich
  • Session-Status erfolgreich
  • Session-TAN-Validierung angelegt und aktiviert
  • Rückmeldung enthält sessionTanActive=true und activatedxFA=true

Direkt danach führt folgender reine Lesezugriff zu einem Fehler:

GET https://api.comdirect.de/api/brokerage/clients/user/v1/depots
Authorization: Bearer <access_token>
Accept: application/json

Antwort:

HTTP/1.1 403 Forbidden

Es werden keine Order- oder sonstigen schreibenden Brokerage-Endpunkte aufgerufen. Das Verhalten tritt sowohl in einer eigenen Read-only-Integration als auch mit der bereitgestellten Postman-Collection auf.

Der Support wies darauf hin, dass OAuth-Credentials stets für die Kontoverbindung gelten, in der sie angelegt wurden, und dass bei fehlendem Depot in dieser Verbindung ein 403 zurückgegeben wird. Nach meiner Prüfung wurden der OAuth-Client und die verwendeten Credentials jedoch im selben persönlichen Zugang erzeugt, in dem das Depot im Webbanking sichtbar ist.

Hat jemand ein vergleichbares Verhalten erlebt oder kann Hinweise geben zu:

  • weiteren Voraussetzungen für den Depot-Endpunkt,
  • erforderlichen Headers neben Authorization und Accept,
  • möglichen Besonderheiten bei mehreren Konten/Depots bzw. Zugängen,
  • einer Methode, die dem OAuth-Client zugeordnete Kontoverbindung technisch zu prüfen?

Zugangsdaten, Tokens, Client Secret, Zugangsnummer und PIN kann ich selbstverständlich nicht veröffentlichen. Gern liefere ich anonymisierte Request- und Response-Header nach.

Vielen Dank!

dg2210
Legende
8.284 Beiträge

@MichaM21  schrieb:

Hallo zusammen,

ich erhalte beim Abruf meiner Depotliste über die comdirect REST API einen HTTP-Status 403 Forbidden.

 


Meinst du: " Alle anderen API-Endpunkte funktionieren, lediglich der Depotabruf liefert 403 forbidden. " ?

Bettina Orlopp : „Wir haben kein Erkenntnis-, sondern ein Umsetzungsproblem.“ (Focus online 24.06.2025)

MichaM21
Autor ★
4 Beiträge

Hallo zusammen,

ja, genau. Der OAuth-Login, der Abruf des Session-Status sowie der komplette Session-TAN-Ablauf funktionieren erfolgreich. Auch die Aktivierung wird mit sessionTanActive=true und activatedxFA=true bestätigt.

Lediglich der anschließende, rein lesende Depotabruf

GET /api/brokerage/clients/user/v1/depots

liefert HTTP 403 Forbidden.

Getestet wurde dies sowohl mit der offiziellen comdirect-Postman-Collection als auch mit einer eigenen Read-only-Integration – jeweils mit demselben Ergebnis.

Viele Grüße
Dr. Michael Marré

dg2210
Legende
8.284 Beiträge

@MichaM21  schrieb:

Hallo zusammen,

ja, genau. Der OAuth-Login, der Abruf des Session-Status sowie der komplette Session-TAN-Ablauf funktionieren erfolgreich. Auch die Aktivierung wird mit sessionTanActive=true und activatedxFA=true bestätigt.

Lediglich der anschließende, rein lesende Depotabruf

GET /api/brokerage/clients/user/v1/depots

liefert HTTP 403 Forbidden.

Welche anderen Endpunkte hast du getestet?

Bettina Orlopp : „Wir haben kein Erkenntnis-, sondern ein Umsetzungsproblem.“ (Focus online 24.06.2025)

javadoc133
Einsteiger
1 Beiträge

Hast du mal die Version v3 probiert? Ich denke die steht in der aktuellen Doku... 

MichaM21
Autor ★
4 Beiträge

Hallo zusammen,

ich habe den Test nochmals vollständig mit der offiziellen comdirect-Postman-Collection durchgeführt.

Der Fehler tritt damit auch direkt in der offiziellen Postman-Collection auf – unabhängig von unserer eigenen Anwendung, Browserdaten oder einer abweichenden API-Version.

Bitte geben Sie den Vorgang daher an das zuständige REST-API-/Berechtigungsteam weiter. Es sollte geprüft werden, weshalb der OAuth-Client bzw. der zugehörige Zugang trotz erfolgreicher Authentifizierung und aktivierter Session-TAN keinen Zugriff auf die Depotliste erhält.

Viele Grüße
Dr. Michael Marré

Thorsten_
Legende
5.157 Beiträge

@MichaM21  schrieb:

 

Bitte geben Sie den Vorgang daher an das zuständige REST-API-/Berechtigungsteam weiter.


Um sicherzugehen, dass "die Bank" mitliest: @SMT_Service zur Kenntnis.

MichaM21
Autor ★
4 Beiträge

Hallo zusammen,

mein HTTP 403 Forbidden beim Depotabruf ist gelöst.

OAuth-Login, Session-Status und Session-TAN-Aktivierung hatten bereits funktioniert. Trotzdem lieferte der Aufruf

GET /api/brokerage/clients/user/v3/depots

immer 403 Forbidden.

Die Ursache war, dass nach der TAN-Aktivierung noch zwingend der Schritt „OAuth2 CD Secondary Flow“ aus Kapitel 2.5 der API-Dokumentation ausgeführt werden muss.

Der Ablauf ist:

2.1 OAuth Resource Owner Password Credentials Flow
→ 2.2 Session-Status
→ 2.3 Session-TAN anfordern
→ 2.4 Session-TAN aktivieren
→ 2.5 OAuth2 CD Secondary Flow
→ Depot-/Positions-Endpunkte aufrufen

Der Token aus Schritt 2.1 besitzt nur die Berechtigung TWO_FACTOR und darf für den Session-TAN-Ablauf verwendet werden. Erst Schritt 2.5 liefert einen neuen Access-Token mit den Berechtigungen für die lesenden und schreibenden API-Endpunkte.

Wichtig: Für den Depotabruf muss anschließend wirklich der neue Token aus Schritt 2.5 verwendet werden.

Danach funktionierten bei mir sowohl Depotliste als auch Positionsabruf erfolgreich.

dg2210
Legende
8.284 Beiträge

@MichaM21  schrieb:

 

Die Ursache war, dass nach der TAN-Aktivierung noch zwingend der Schritt „OAuth2 CD Secondary Flow“ aus Kapitel 2.5 der API-Dokumentation ausgeführt werden muss.

 


Jetzt widersprichst du dir aber selbst. Ich hatte weiter oben explizit gefragt, ob alle anderen API-Endpunkte funktionieren. Du hast mit 'ja genau' geantwortet. 

 

Das kann nicht sein, denn wenn du den secondary flow weglässt, dann funktioniert praktisch gar nichts. Deine falsche Antwort oben hat uns alle aufs Glatteis geführt.

 

 

Bettina Orlopp : „Wir haben kein Erkenntnis-, sondern ein Umsetzungsproblem.“ (Focus online 24.06.2025)