XeroAPI / Xero-OpenAPI

An OpenAPI description of the Xero API

Home Page:https://developer.xero.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Accounting BatchPaymentDetails invalid length on details property

judgej opened this issue · comments

The BatchPaymentDetails model includes a property details that is limited to 18 UTF-8 characters. This field is used when creating batch payments to be used as the bank payment reference, which is also limited to 18 limited ASCII characters as a limitation in the Bacs service.

The issue is that the details field in the Xero GUI is not limited to 18 characters, and so blows up the API XeroAPI\XeroPHP\Models\Accounting\BatchPaymentDetails model on receipt of a batch payment response here:

https://github.com/XeroAPI/xero-php-oauth2/blob/master/lib/Models/Accounting/BatchPaymentDetails.php#L318

and marked as invalid here:

https://github.com/XeroAPI/xero-php-oauth2/blob/master/lib/Models/Accounting/BatchPaymentDetails.php#L217

The same may also happen for other generated languages, but I haven't looked.

I haven't experimented with the details field enough to determine the maximum length that a user can enter, but I guess the API description needs to specify the real maxium length. It is acceptable that the application - if it needs to use the details as a Bacs reference - truncates the string to 18 characters, since it also needs to transform the UTF-8 string to the limited ASCII characters that Bacs accepts anyway.

This is where it is defined:

https://github.com/XeroAPI/Xero-OpenAPI/blob/master/xero_accounting.yaml#L18997

image

Hi - quick question: was this 18 char length limit validation released to the UI in the last 24 hours? We had clients sending us long "details" yesterday, and now we can't seem to reproduce that ourselves through the front end today. Awesome if it has.

Hey @judgej

This OpenAPI spec is independent of our product and APIs. Changes to our OpenAPI spec only impact our SDKs.

So, I can't say if/when the UI or API validation changed. What we do know is data returned from the API exceeded the maxlength on that property and caused errors to be thrown on deserialization. To address this we removed the maxlength.