What’s new in v2024-01-31
Stay up to date with the latest features, improvements, and breaking changes in the current version of Monite API.
Overview
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.
Accounts Receivable: Full coverage and regulatory compliance for the US
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.
Improved data validation
API version 2024-01-31 introduces additional validations and requirements for entity data, which helps streamline the entity onboarding process.
- Entities:
- Empty string values (
""
) are no longer allowed in entity data. To indicate the absence of a value, either use thenull
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
and13475550100
are considered valid phone numbers even though they are fictitious.- For organizations:
legal_name
can be up to 100 characters long.
- For individuals:
first_name
,last_name
, andid_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.
- Empty string values (
- 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
anddisplay_name
can be up to 200 characters long.bic
cannot be provided withoutiban
.
- Entity persons:
- Empty string values (
""
) are no longer allowed in persons’ data. To indicate the absence of a value, either use thenull
value or omit the corresponding field from the request. first_name
,last_name
,id_number
, andtitle
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
andaddress.state
can be up to 100 characters long.address.line1
andaddress.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
and13475550100
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.
- Empty string values (
Other features and improvements
- Added support and regulatory coverage for the USA. US-based entities can now issue invoices to their customers using the Monite API.
- Added the ability to create multiple overdue reminders using the
terms
field on the request object of thePOST /overdue_reminders
andPATCH /overdue_reminders
. - Persons have a new read-only field
created_by_entity_user_id
that contains the ID of the entity user who created this person.
Breaking changes
Version 2024-01-31 includes the following breaking changes, which you should consider when upgrading from the previous API version.
-
General:
- Removed the deprecated country code
CS
(Serbia and Montenegro) in favor ofRS
(Serbia) andME
(Montenegro).
- Removed the deprecated country code
-
Entities:
- The
country
of existing entities can no longer be changed for regulatory reasons. - Possible currencies for entity bank accounts now depend on the bank country:
- USD can only be chosen for bank accounts in the US.
- GBP can only be chosen for bank accounts in the UK (including Gibraltar).
- EUR can only be chosen for bank accounts in the EU, Liechtenstein, Norway, Switzerland, and UK (including Gibraltar).
- See the Improved data validation section for other changes.
- The
-
Counterparts:
- Removed the
created_automatically
field from the request payload when creating and updating counterparts. - Removed the
type
field from the request payload of thePATCH /counterparts/{counterpart_id}
endpoint.
- Removed the
-
Counterpart addresses:
- The
individual.residential_address
andorganization.registered_address
fields in thePOST /counterparts
request body have been renamed toindividual.address
andorganization.address
, respectively. - Removed the ability to manually set a default counterpart address using the
POST /counterparts/{counterpart_id}/addresses/{address_id}/make_default
endpoint. - Removed the
is_default
field from counterpart addresses.
- The
-
Counterpart bank accounts:
- Renamed the
is_default
field in counterpart bank accounts tois_default_for_currency
.
- Renamed the
-
Mail templates:
- The
body_text
variable of thebody_template
field in the request body of thePOST /mail_templates
andPATCH /mail_templates
endpoints was renamed tobody_template
.
- The
-
Overdue reminders:
- The
term
field in thePOST /overdue_reminders
andPATCH /overdue_reminders/{overdue_reminder_id}
endpoints was renamed toterms
. The field now accepts an array of objects to support creating multiple overdue reminders.
- The
-
Payables:
- Payables in the
approve_in_progress
status can no longer transition to thecanceled
status. - The
due_date*
query filters inGET /payables
now expect just a date value without the time part, that is,YYYY-MM-DD
instead ofYYYY-MM-DDThh:mm:ssZ
.
- Payables in the
-
Receivables:
- Removed the
country
,currency
,display_name
,is_default
, andwas_created_by_user_id
fields from theentity_bank_account
object in invoice, quote, and credit note responses. - Removed the
counterpart_billing_address
andcounterpart_shipping_address
fields from the request payloads of thePOST /receivables
andPATCH /receivables/{receivable_id}
endpoints. - The request payloads of the
POST /receivables
andPATCH /receivables/{receivable_id}
endpoints now usecounterpart_billing_address_id
andcounterpart_shipping_address_id
fields rather than objects. Thecounterpart_billing_address_id
field is now required when creating new invoices and quotes. - Removed the
counterpart_address
object from receivables’ response objects. - The
counterpart_billing_address_id
field is required in the payload of thePATCH /receivables/{receivable_id}
endpoint whenever the counterpart associated with the receivable is changed.
- Removed the
-
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:
- Renamed the
name
field todescription
. - Removed the
significance
field. - Replaced the
object_id
field with the nestedobject.id
field.
- Renamed the
-