Transactions timestamp is wrong #110
Comments
|
I think the API contains two date fields, one when the transaction was created and another when it was actualy fully processed. Currently we only show one of them and never switch between the two. |
|
Hi @markusressel, unfortunately I can only speak for my use case which is running a cronjob every day that gets all the transactions I've made during the day and bring them to another application. So, for me, the reference timestamp is what I can see on the app and I think it's the "created" one. By the way, all the timestamps I get now on the dictionary returned by APIs are "wrong", in relation to what I see on the app and I'm quite sure that approximately one week ago it was working well |
|
The app is using a new endpoint for transactions : |
|
It might be possible to add support for this endpoint, but its output is pretty limited by default, contains other stuff beside transactions, and I am not sure how filtering works (the old parameters don't seem to have any effect). I think for this to be useful we would need at least some kind of working date filtering. Is there anything out there that we could build off of? |
|
You can use Example of filter: |
|
Not sure where you get your infos from, but we need more of them if we want to get this to work 😄 Querying result = self._do_request(GET, BASE_URL_DE + f'/api/feed/v2')Querying result = self.get_account_info()
account_id = result["id"]
filters = []
if from_time is not None and to_time is not None:
filters.append(
{
"criteria": {
"from": from_time,
"to": to_time
},
"type": "DATE_RANGE"
}
)
result = self._do_request(GET, BASE_URL_DE + f'/api/feed/accounts/{account_id}/transactions/search', json={
"filterCriteria": {
"filters": filters
},
"searchText": text_filter
}) |
Inspecting the http traffic from the android app.
It's a POST, not a GET. |
|
Still fails, now with a But I had a look at the {
'id': 'redacted',
'title': 'Steam',
'subtitle': {
'template': '1 Feb · Online'
},
'tintedSubtitle': {
'elements': [
{
'value': '1 Feb · Online'
}
]
},
'amount': -6.78,
'amountStyle': 'NONE',
'currency': 'EUR',
'timestamp': 1643738003158,
'type': 'TRANSACTION',
'category': 'micro-v2-media-electronics',
'highlight': 'NONE',
'icon': {
'type': 'MERCHANT',
'url': 'https://cdn.number26.de/feed/merchants/5102.png'
},
'balance': {
'title': 'Balance on {{date}}',
'amount': redacted,
'currency': 'EUR'
},
'deeplink': 'number26://main/detail/redacted',
'gestures': {
'swipeLeft': {
'description': 'Pay back from a Space',
'deeplink': 'redacted',
'tracking': {
'action': 'feed.gesture_swipe.left',
'category': 'engagement',
'property': 'payback'
}
}
}
}Not sure whats going on here, but there is probably more to it than just a different endpoint. |
|
Timestamp issue: make sure you have all these headers properly set: |
|
For the 500 error: my guess is that it's either the missing headers, or something is wrong with your json content. |
|
Adding both of the The old API does still not show the correct dates (which is not a problem if we get the new one to work). However, even adding all 4 headers doesn't fix the {
"filterCriteria": {
"filters": [
{
"criteria": {
"from": 1643628699863,
"to": 1643747219000
},
"type": "DATE_RANGE"
}
]
},
"searchText": "Music"
}Maybe the account-uuid is not the correct/same as in the old API? |
This is precisely why I suggested using the new endpoints.
I don't get a 500 when sending the json content you've pasted.
Yes, it's the same. At least for me. There must be something wrong in your headers (content-type ?) |
|
These are all the headers that I tried: I also tried just the |
|
I also just tried the same in Hoppscotch, also doesn't work. I get the same |
|
What about device-token ? |
|
Still |
|
It might be easier for you to check on your end, which changes to the query (omission of headers etc) result in a |
|
Sure, I'll try to do that. |
|
Using postman, I've tested removing pretty much everything except the authorization header, and it still works. |
|
I cannot get any closer without installing postman: Fails with Can you test if (somehow) using HTTP/1.0 breaks it? I also tried the same through the hotspot of my phone to make sure my local network isn't acting up, still Can anybody else verify if this only happens to me? |
|
I think it would be better to implement a basic client of this new endpoint (in a new branch) and let people (including you and me) test it using the lib instead of doing manual requests. It's the only way to make sure we're all using the same headers and protocol. |
|
@tranb3r @markusressel Does it maybe make sense to set up a workspace on Hoppscotch or Postman instead of having a branch for API testing? I think in the long run API endpoint health questions will come up again and again. Maybe this could provide us more transparency without having to create new debugging branches? |
|
I don't know anything about workspaces on Hoppscotch or Postman, but if you think it could be useful, let's try it ! |
That's the reason that's been holding me back so far from using it. I don't think think that it's unsafe from the authentication perspective, since our phones are the second factor. But I am not sure at the moment how each of these handle the API responses and if they might store them (sensitive data like transactions etc.). |
|
Hi @femueller , i'm using this package for a personal project. When I call the api_client.get_transactions() I can't see the Date columns. Is this feature currently disabled? |
|
The last release of python-n26 was released 8 months before this issue was opened, so no, we didn't disable anything 😄 |
|
@markusressel I had the error 500 like you because for the call to /api/feed/accounts/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/transactions/search I used userId (retrieved from /oauth2/token or /api/me response) instead of accountId (you can find it inside the /api/feed/v2 or /api/smrt/transactions response). |
|
For all of my tests I used the Requesting the However, I am not quite sure how the API is intended to be used correctly then, since I can't imagine you have to fetch the feed to get the accountId from one of the items in the list? 🤔 This just doesn't look right 😆 account_id = list(filter(lambda x: x["type"] == "TIMELINE", result["modules"]))[0]["items"][0]["accountId"]@tranb3r Where did you get the Also, would you be able to find out the schema of other filters, if there are any? |
|
I'm requesting |
|
@tranb3r that would be great, so we can give users the most flexibility. I hope you can reuse the setup you used preciously and safe some time. I will try if that works out the next thing I am thinking about is how to proceed with our API client. Should this be a new method or should this replace the existing API? The latter would be a breaking change, although I don't think many people would be affected by this since the old API is broken anyway... Same goes for the CLI client, although for that I think it doesn't make a lot of sense to support the old API at all. @femueller any thoughts on that? |
|
You can now get Here is the schema for transactions filter ( For the Hope this helps! |
|
Yes thats very helpful! ❤️ Also these scenarios would be of interest:
Basically: Click on every single screen and button within the app once 🤣 Sorry for "abusing" you here, but if we can figure this out we can create a pretty nice API from it! 🤓 |
|
For infinite scrolling, you can use the Tags and merchants are just values you put in the Suggestions: POST |
|
Awesome! I don't know when I will get to it, but this should provide a good basis for an implementation. I will keep you updated. |
Very much agreed on that. We could create a new Major release for that if we have any breaking changes. |
Hi all,
just to report that I'm noticing that the transactions timestamps retrieved via api, don't match the actual timestamps on the app. For example, if you take the first transaction from this list (via CLI)
reports that the transaction was carried out on January 25 but in the app I get Saturday, January 22 (which is the correct date) :
Same example via API:
visibleTS is 1643092168637 which converted turns out to be Tuesday 25 January 2022 06:29:28.637
maybe something has changed on the API side ?
Thanks
The text was updated successfully, but these errors were encountered: