GET account transactions, incomplete list of transactions / page count does not work

[itaBlackHawk]

Hi, first of all, thanks for this well-packed API!

While I was trying to put together my first python program interacting with this API, I stumbled upon an issue, which I am not sure if it's mine / this API or (probably) comdirect fault.

If I try to retrieve all my transactions:

transactions = client.get('/banking/v1/accounts/{}/transactions'.format(accountId))
print (json.dumps(transactions['paging'], sort_keys=True, indent=4))
>>> {
    "index": 0,
    "matches": 46
}

As I got much more than 46 transactions, something is going wrong. Trying with:

transactions = client.get_account_transactions(accountId)

returns the same results. Ideas? Is it an intrinsic limit of this API?
While trying to dig into this issue I dug into get_account_transactions function and found the paging_count and paging_first parameters. Those are not documented in the official PDF/Postman JSON and manipulating them does not give any different results.. does anyone had successfully tested them?

Thanks!

[alex-kn]

Hi, thanks for the kind words.

I actually have the same issues with the transaction API, only shows the last 58 for me, also when using the Rest API directly (w/ postman). I suppose this is a limitation on comdirect's side, I couldn't figure out how to fetch more transactions.

The paging works correctly for me, even though this is not documented in the PDF. Note paging_first only is supported by comdirect for BOOKED transactions (the endpoint responds with an error otherwise). But even with paging, the result never exceeds beyond the 58th transaction for me.

Unfortunately comdirect does not provide a test server (yet?), against which we could write some tests :(

[itaBlackHawk]

Hi Alex,
I asked on comdirect forum ( https://community.comdirect.de/t5/Website-Apps/REST-API-Abruf-Kontoums%C3%A4tze-ist-begrenzt/m-p/164369 ) and it seems the transactions are limited to the last 180 days, here is the problem!
On my personal APP i "resolved" that by adding manually the old transactions, and keeping a database seems the only possible solution to keep a record.

Thank you for the clarification on paging firstI wonder where anyone found those possibility.. maybe there is possible also a solution for searching older transaction?

Frohes neues!

[alex-kn]

Okay, I didn't know about the 180 days, thanks for clarifying!

Maybe there is a possibility (like in the browser), but we might never know until the documentation gets updated (or someone stumbles upon the solution). The paging functionality is documented for other endpoints, not for transactions, but also works for transactions (and probably others).

Happy New Year!

[itaBlackHawk]

I got a reply from comdirect, referencing this thread https://community.comdirect.de/t5/Website-Apps/Mehr-als-20-Depot%C3%BCms%C3%A4tze-per-REST-API-abrufen/m-p/166206/highlight/true#M15300 :

Es gibt aber ein paar Tricks, die es noch nicht in die Doku geschafft haben. Ihr könnt mit den Query-Parametern „min-bookingDate“ und „max-bookingDate“ ein Zeitfenster festlegen. Zum Beispiel können mit einer Anfrage mit diesem Query-Teil: „min-bookingDate=2020-10-01&max-bookingDate=2020-11-01“ die Umsätze des Monats Oktober abgerufen werden. Es kann auch nur der Parameter „min-bookingDate“ verwendet werden, um ein Anfangsdatum festzulegen.


Mit dem Parameter „paging-count“ kann die Größe der Ergebnismenge verändert werden (Standardwert ist 20) und mit „paging-first“ kann der Startindex der abgefragten Menge (Standard ist hier 0) beeinflusst werden.


Für die Depotumsätze gilt das folgende:


Die Schnittstelle für die Depotumsätze liefert max. 20 Ergebnisse und nur Umsätze der letzten 180 Tage. Beides lässt sich aktuell nicht ändern, der Wunsch ist aber bekannt. Als „Workaround“ können wir nur den Trick verraten, mithilfe der folgenden Request-Parameter die Ergebnismenge einzuschränken, um in der Summe mehr Depotumsätze zu erhalten: wkn/isin/instrumentId, bookingStatus (NOTBOOKED/BOOKED/BOTH) oder min-bookingDate.

that could be quite useful, it seems indeed is possible to select more than 180 days!

[alex-kn]

Very nice! With setting min-bookingDate it is actually possible to query more transactions. I'll add the query parameters to the request.

Thank you for that!