What’s new in v2024-01-31
What’s new in v2024-01-31
What’s new in v2024-01-31
This version includes improvements and changes to the Monite platform to make the API more consistent and predictable.
In future updates to the API version 2024-01-31, we plan to add more features and improvements to our product offering. We’ll add these new features to the current API version unless they introduce new breaking changes. In such cases, we will introduce them in subsequent API versions.
With every platform release, we expand the geographic coverage of the regions and countries supported by our product verticals.
As of v. 2024-01-31, we have provided the final elements necessary to expand our coverage to offer full regulatory compliance in the US. This milestone allows US entities to leverage Monite’s accounts receivable functionality using our API. With this expansion, our partners can deliver enhanced financial services to their customers across the US market, unlocking new opportunities for growth and innovation.
This release includes requirements for standard invoice data elements, invoice templates, the ability to select custom sales tax amounts on invoices and quotes, and more.
API version 2024-01-31 introduces additional validations and requirements for entity data, which helps streamline the entity onboarding process.
Entities:
"") are no longer allowed in entity data. To indicate the absence of a value, either use the null value or omit the corresponding field from the request.address.city can be up to 100 characters long.address.line1 can be up to 200 characters long.business_profile.mcc (specified via /entities/{entity_id}/onboarding_data) must be a valid MCC according to ISO 18245:2023. See Merchant category codes for a list of accepted codes.phone pattern and length are now validated based on the country code of the phone number. However, we do not verify if the number is actually in use. For example, +1 (347) 555-0100 and 13475550100 are considered valid phone numbers even though they are fictitious.legal_name can be up to 100 characters long.first_name, last_name, and id_number can be up to 100 characters long.date_of_birth - the individual must be at least 13 years old.ssn_last_4 must be a 4-character numeric string.title can be up to 10 characters long.Entity bank accounts:
sort_code must be a 6-character numeric string.routing_number of US bank accounts must be a 9-character numeric string.account_number must be a numeric string. UK account numbers must be 8 characters long, and non-UK account numbers can be 5-19 characters long.account_holder_name and display_name can be up to 200 characters long.bic cannot be provided without iban.Entity persons:
"") are no longer allowed in persons’ data. To indicate the absence of a value, either use the null value or omit the corresponding field from the request.first_name, last_name, id_number, and title can be up to 100 characters long.date_of_birth - the person must be at least 13 years old.address.country must be a valid two-letter country code (ISO 3166-1 alpha-2).address.city and address.state can be up to 100 characters long.address.line1 and address.line2 can be up to 200 characters long.address.postal_code can be up to 10 characters long.phone pattern and length are now validated based on the country code of the phone number. However, we do not verify if the number is actually in use. For example, +1 (347) 555-0100 and 13475550100 are considered valid phone numbers even though they are fictitious.relationship.percent_ownership can have at most two decimal places.ssn_last_4 must be a 4-character numeric string.terms field on the request object of the POST /overdue_reminders and PATCH /overdue_reminders.created_by_entity_user_id that contains the ID of the entity user who created this person.Version 2024-01-31 includes the following breaking changes, which you should consider when upgrading from the previous API version.
General:
CS (Serbia and Montenegro) in favor of RS (Serbia) and ME (Montenegro).Entities:
country of existing entities can no longer be changed for regulatory reasons.Counterparts:
created_automatically field from the request payload when creating and updating counterparts.type field from the request payload of the PATCH /counterparts/{counterpart_id} endpoint.Counterpart addresses:
individual.residential_address and organization.registered_address fields in the POST /counterparts request body have been renamed to individual.address and organization.address, respectively.POST /counterparts/{counterpart_id}/addresses/{address_id}/make_default endpoint.is_default field from counterpart addresses.Counterpart bank accounts:
is_default field in counterpart bank accounts to is_default_for_currency.Mail templates:
body_text variable of the body_template field in the request body of the POST /mail_templates and PATCH /mail_templates endpoints was renamed to body_template.Overdue reminders:
term field in the POST /overdue_reminders and PATCH /overdue_reminders/{overdue_reminder_id} endpoints was renamed to terms. The field now accepts an array of objects to support creating multiple overdue reminders.Payables:
approve_in_progress status can no longer transition to the canceled status.due_date* query filters in GET /payables now expect just a date value without the time part, that is, YYYY-MM-DD instead of YYYY-MM-DDThh:mm:ssZ.Receivables:
country, currency, display_name, is_default, and was_created_by_user_id fields from the entity_bank_account object in invoice, quote, and credit note responses.counterpart_billing_address and counterpart_shipping_address fields from the request payloads of the POST /receivables and PATCH /receivables/{receivable_id} endpoints.POST /receivables and PATCH /receivables/{receivable_id} endpoints now use counterpart_billing_address_id and counterpart_shipping_address_id fields rather than objects. The counterpart_billing_address_id field is now required when creating new invoices and quotes.counterpart_address object from receivables’ response objects.counterpart_billing_address_id field is required in the payload of the PATCH /receivables/{receivable_id} endpoint whenever the counterpart associated with the receivable is changed.Webhooks:
Renamed the /webhook_settings endpoints to /webhook_subscriptions.
Renamed the /webhooks endpoints to /webhook_deliveries.
Changed the success status code for POST /webhook_subscriptions from 200 to 201.
Changed the success status code for DELETE /webhook_subscriptions/{webhook_subscription_id} from 200 to 204.
Changes in the webhook event format:
name field to description.significance field.object_id field with the nested object.id field.