Special Characters in names aren't handled well by some APIs
in alpha
J
JP Shipherd
Names with special characters in them get a bit mangled in the API. For example I have a category called "Auto & Transport".
If I call GET /categories/{id} with this ID I get a response body with the following attribute:
"name": "Auto & Transport",
-- If I then pass this response body into the PUT or POST /categories API it treats this as a different name, and uses this as the literal string. See the screenshot of the Categories page after doing a POST /categories
Ideally, the API would massage out the "amp;" part of the string.
Log In
Din from Lunch Money
Merged in a post:
Unescape category names in API response
Jen from Lunch Money
From Discord––
Justin Flannery
I'm working on updating the Python client and encountered an interesting issue. The /v1/categories API is supposed to return 40 characters max for the name field - but sometimes it escapes characters (i.e. Payment/Transfer) causing the length to be > 40. Is this a bug or expected behavior? Should the API client allow for Category objects with len(name) > 40 to be read from the API? (https://github.com/juftin/lunchable/issues/96)
J
JP Shipherd
marked this post as
in alpha
This issue is fixed in the v2 API available in open Alpha here: https://alpha.lunchmoney.dev/v2/docs.
V1 API requests made to api.lunchmoney.dev will benefit from these fixes as well.
J
JP Shipherd
More details on this from Dino on Discord
1) Some characters (<>&) get escaped as XML entities. E.g. & is replaced with &. This is extremely unexpected since it breaks my deduplication on external_id and, moreover, it breaks lunchable python client since in expects external_id to be no more than 75 characters (and & is obviosuly much longer than a plain &).
2) Question marks are doing funny things too. I've found out that ?7 sequence in the external_id got replaced with completely unrelated string $1137. To make things more interesting, I get different results when putting the same value in different fields. For example, when putting to external_id, I got $498, but putting the exact same string into notes, I got $497. Unfortunately, I've lost the exact input strings, but I hope this is not too much of a loss :)
3) Backtick is also encoded as XML `, and that's concludes my list of five problematic characters I've found. Replacing these with more safe alternatives allows me to store ascii85-encoded data in external_id without any problems.