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.

These changes are breaking changes.
  • Entities:
    • Empty string values ("") 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.
    • For organizations:
      • legal_name can be up to 100 characters long.
    • For individuals:
      • 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:
    • Empty string values ("") 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.

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 the POST /overdue_reminders and PATCH /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 of RS (Serbia) and ME (Montenegro).
  • 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.
  • Counterparts:

    • Removed the created_automatically field from the request payload when creating and updating counterparts.
    • Removed the type field from the request payload of the PATCH /counterparts/{counterpart_id} endpoint.
  • Counterpart addresses:

    • The individual.residential_address and organization.registered_address fields in the POST /counterparts request body have been renamed to individual.address and organization.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.
  • Counterpart bank accounts:

    • Renamed the is_default field in counterpart bank accounts to is_default_for_currency.
  • Mail templates:

    • The 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:

    • The 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:

    • Payables in the approve_in_progress status can no longer transition to the canceled status.
    • The 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:

    • Removed the 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.
    • Removed the counterpart_billing_address and counterpart_shipping_address fields from the request payloads of the POST /receivables and PATCH /receivables/{receivable_id} endpoints.
    • The request payloads of the 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.
    • Removed the counterpart_address object from receivables’ response objects.
    • The 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:

      • Renamed the name field to description.
      • Removed the significance field.
      • Replaced the object_id field with the nested object.id field.
1{
2 "id": "90cc1b23-9681-40f4-a54b-4c059cd4397d",
3 "created_at": "2024-03-04T20:08:48.399442+00:00",
4 "action": "entity.onboarding_requirements.updated",
5 "api_version": "2024-01-31",
6 "entity_id": "ce0e9fc7-b3e7-4f12-ad86-bfb0725a99f0",
7 "description": "entity_onboarding_requirements_updated",
8 "object": {
9 "id": "ce0e9fc7-b3e7-4f12-ad86-bfb0725a99f0"
10 },
11 "object_type": "entity",
12 "webhook_subscription_id": "c7f37127-44e5-494a-833a-21e60585f187"
13}
For more information on what changes we consider breaking and non-breaking in our API, please refer to our Versioning policy.