Closed mikevmil closed 3 months ago
You're right that the Id is being returned as a string while the documentation suggests that it is an integer.
I've just now released a new patch version that solves this issue. Note that I have implemented a generic CustomFieldAttribute model that replaces the SalesInvoiceCustomField, ExternalSalesInvoiceCustomField, and ContactCustomFieldsAttribute models. As they are equal in terms of properties.
In addition, I noticed that you can only pass an Id and Value on a request but in addition to those properties, you also get a name back in the response. I've added that as well.
Give it a try and let me know if you run into other issues.
When you look at the GET-endpoint for custom fields, you might get the following result (according to the documentation at https://developer.moneybird.com/api/custom_fields/):
This is correct, and is the actual behaviour.
The problem here is that on the following pages: https://developer.moneybird.com/api/sales_invoices/#post_sales_invoices https://developer.moneybird.com/api/contacts/#post_contacts https://developer.moneybird.com/api/identities/#post_identities it wrongfully states that the ID is an Int.
This breaks because the numbers are too large to be parsed as an Int.
I think Moneybirds documentation is wrong here, as the GET-endpoint for custom fields actually returns a string. Could the ID type be changed to string to reflect this? This way it's actually possible to use the custom fields.