NEU: comdirect REST API für Privatkunden

[SMT_Jan-Ove]

Hallo @dg2210,

in der URL wird gemäß Spezifikation eine {userId} erwartet. Anstelle der tatsächlichen Id kann zur Vereinfachung auch der Text „user“ übergeben werden, da wir anhand des Access-Tokens, der im Header übergeben wird, einen Rückschluss auf den angemeldeten Kunden ziehen können.

In Postman wird diese Vereinfachung wie von dir beschrieben genutzt.

Beste Grüße

Jan-Ove

[anton_]

Kann man eigentlich direkt die Konto Transaktionen laden ({{url}}/banking/v1/accounts/{{accountUUID}}/transactions?)?
Wie es aussieht wird dieaccountUUID benötigt, welche aber gar nicht gesetzt ist nachdem ich den ganzen OAuth Flow gemacht habe.

Anscheinend muss ich erst den Kontostand abrufen bevor ich die Transaktionen laden kann, oder gibt es einen anderen Weg?

[SMT_Jan-Ove]

Hallo @anton_,

du hast es genau richtig erkannt: Du musst vorher den Kontostand, sprich Kapitel 4.1.1 „Abruf AccountBalances alle Konten“ abfragen. Dann klappt das auch mit Kapitel 4.1.3 „Abruf Kontoumsätze“. 🙂

Beste Grüße

Jan-Ove

[dg2210]

---

@SMT_Jan-Ove  schrieb:

Hallo @dg2210,

in der URL wird gemäß Spezifikation eine {userId} erwartet. Anstelle der tatsächlichen Id kann zur Vereinfachung auch der Text „user“ übergeben werden,

---

@SMT_Jan-Ove: dann bedeutet Literal "user" in der Schnittstellenbeschreibung genau den Text user. Das war mir nicht klar...

Andere Sache: Es scheint so, dass der Accept-Header immer application/json lauten muss. Dies ist aber in der Schnittstellenschreibung nicht sofort ersichtlich.

[SMT_Jan-Ove]

Danke für deine Rückmeldung, @dg2210.

Deinen Hinweis habe ich gerne weitergegeben. 🙂

Beste Grüße

Jan-Ove

[SMT_Erik]

---

@dg2210  schrieb:

....

---

Andere Sache: Es scheint so, dass der Accept-Header immer application/json lauten muss. Dies ist aber in der Schnittstellenschreibung nicht sofort ersichtlich.

---

Oh doch, @dg2210 , es steht* in Kapitel 3.3 (Header sämtlicher weiterer Schnittstellen).

Gruß aus Quickborn

Erik

* ... sagen die lieben Kollegen aus der Fachabteilung. Ja, die gibt es wirklich!

[dg2210]

---

@SMT_Erik  schrieb:

---

@dg2210  schrieb:

....

---

Andere Sache: Es scheint so, dass der Accept-Header immer application/json lauten muss. Dies ist aber in der Schnittstellenschreibung nicht sofort ersichtlich.

---

Oh doch, @dg2210 , es steht* in Kapitel 3.3 (Header sämtlicher weiterer Schnittstellen).

---

Bei  der veröffentlichten Version leider nicht (da wird der Header nur als Beispiel bezeichnet) (Im Übrigen bin ich erst bei Schritt 2.3)...

[dg2210]

(gelöscht)

[SMT_Erik]

Danke für deinen Hinweis @dg2210.

Der Aufbau des Headers entspricht tatsächlich immer dem Beispiel in Kapitel 3.3. Dieser ist aber „beispielhaft“, da die dort angegebenen Werte natürlich variieren.

Dem Fachteam ist bei der Analyse deiner Frage aber aufgefallen, dass die Dokumentation in Kapitel 9 (DOCUMENTS-Schnittstellen) bzgl. des Headers nicht konkret genug ist und hat soeben ein Update veranlasst. Dieses steht in Kürze im API-Downloadbereich zur Verfügung (Version Februar 2020 – Update 1).

Gruß aus Quickborn

Erik

[dg2210]

---

@SMT_Erik  schrieb:

Dem Fachteam ist bei der Analyse deiner Frage aber aufgefallen, dass die Dokumentation in Kapitel 9 (DOCUMENTS-Schnittstellen) bzgl. des Headers nicht konkret genug ist und hat soeben ein Update veranlasst. Dieses steht in Kürze im API-Downloadbereich zur Verfügung (Version Februar 2020 – Update 1).

Ich bekomme beim Dokumentabruf von nur eine Liste der ersten 20 Dokumente zurück. Hat das damit zu tun?