Max length for memo and payee_name does not match what YNAB allows

[davidstosik]

Hi there! 👋🏻
First I've got to state again how happy I am using YNAB and the API for my own workflow, this is working great!

I recently noticed that some field maximum lengths might not match the actual length limits when using the YNAB web client.

In short, the OpenAPI spec file specifies a maxLength for payee_name and memo fields of respectively 50 and 200, but it's been possible for a long time to create transactions with longer payee name and memo. (I just created a transaction with a 10,000-character long memo!)

I think this issue is very similar to this other issue I opened back in February last year: Validation error on API response for TransactionDetail#import_payee_name, and that it could get a similar fix (Remove unnecessary maxLength validation for import payee fields).

One thing I noticed that might have not been the case last year, is that even if I remove the validations Ruby-side, the API actually responds with an error too:

{"error":{"id":"400","name":"bad_request","detail":"memo is too long (maximum is 200 characters) (index: 19), memo is too long (maximum is 200 characters) (index: 36), memo is too long (maximum is 200 characters) (index: 37)"}}

I could imagine this is happening if YNAB's API server code is also generated with the OpenAPI Generator, based on the same OpenAPI spec. In this case, the fix would require not only a new version of this gem but also an update of YNAB's server-side API code.

Hope this makes sense, but feel free to let me know if you need more details! 🙏🏻

[bradymholt]

@davidstosik thanks for the feedback!

The API does indeed have smaller limits for some fields; this is intentional and by design. Having said that, if you have a specific use case for increasing these a bit, we can consider that.

[davidstosik]

@bradymholt thanks for the reply!

As for a use case, you can check my previous issue that I linked in the description above: basically, it's impossible to write a script that fetches existing transactions, changes them then saves them again, since you might be fetching transactions that were created in the UI and will appear invalid from the API.

I sometimes use the description to take notes about a given transaction and it can exceed 200 chars, seldomly.
As for the payee, I've had cases where the payee shown in the transaction fetched from my bank records exceeds 50 characters. (And CSV import imported it flawlessly.)

[bradymholt]

Ah, I see. Thanks for the context. As I mentioned, we intentionally limit these in the API to prevent abuse. Is there a limit we could increase it to (short of the limit the apps allows) that would allow you to proceed, even if you needed to trim in some cases when saving a transaction from the API?

[davidstosik]

@bradymholt Sorry it took me some time to get back to you.
I took a look at my whole budget:

# frozen_string_literal: true

require "ynab"

puts "Fetching data..."

ynab_api = YNAB::API.new(ENV["YNAB_ACCESS_TOKEN"])
budget = ynab_api.budgets.get_budgets.data.budgets.sort_by(&:last_modified_on).last
transactions = ynab_api.transactions.get_transactions(budget.id).data.transactions

puts <<~OUTPUT
  Fetched #{transactions.count} transactions.
  Three longest memo sizes: #{transactions.filter_map(&:memo).map(&:length).uniq.max(3).join(", ")}
  Three longest payee name sizes: #{transactions.filter_map(&:payee_name).map(&:length).uniq.max(3).join(", ")}
OUTPUT

Fetching data...
Fetched 5225 transactions.
Three longest memo sizes: 273, 200, 199
Three longest payee name sizes: 100, 98, 92

So I've got old transactions in my budget with memo and payee name that exceed the current validations. (I'm actually surprised the YNAB gem did not fail to load the data, as it does with invalid flag colors, here. 😅)

I'm writing an import script that allows me to import into YNAB transactions from my various Japanese bank accounts. (There's no account linking here!)
One peculiarity is using a separate account for Amazon transactions, where I'd like to use the product name as memo.
That's where I hit a wall, as some Amazon product names can easily exceed the 200-character limit.
The payee name is less of a problem I guess.

I understand that removing the limits would favor abuse, but do you think that it would be possible to:

1. augment the current limits for memo and payee name to respectively 500 and 200 characters?
2. maybe add those limitations to the UI as well, preventing discrepancy between UI and API? (Currently, how would I save a transaction that I fetched using the API then modified locally, if it has an invalid memo?)

[bradymholt]

@davidstosik - Thanks for the feedback. I understand the friction that can be caused by having different limits on the clients and the API. I'll raise this internally to see about some better alignment there. In the meantime, we can increase the limits on allowed by the server for memo and payee_name to 500 and 200, respectively. We'll work on a server change to get this out.

[bradymholt]

Update - This increase in limit is scheduled to ship early next week.

[davidstosik]

@bradymholt thank you very much!

[davidstosik]

@bradymholt May I ask for an update on this? (Nothing urgent, just wondering if anything went out, since I don't see a new release of the gem.) 🙏🏻

[bradymholt]

@davidstosik - The server change (1.72.1) went out back in July but we didn't mention on the release notes since it was a very minor patch. Honestly, I didn't think a new client would be needed for this change but now I see that indeed there is a some validation logic that checks the length against the spec. I'll cut a new release here in just a minute! Thanks for the ping.