> This page is for version v2024-01-31.
> For other versions, use one of these documentation indexes:
> - v2024-05-25 (default): https://docs.monite.com/v-2024-05-25/llms.txt
> - v2024-01-31: https://docs.monite.com/v2024-01-31/llms.txt
> - v2023-09-01: https://docs.monite.com/v2023-09-01/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.monite.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.monite.com/_mcp/server.

# What's new in v2024-01-31

## Overview

This version includes improvements and changes to the Monite platform to make the API more consistent and predictable.

> **Info**
>
> 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.

> **Warning**
>
> 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](../../payments/mcc) 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](../../accounts-receivable/regulatory-compliance/countries) 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](#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.

#### v2024-01-31

```json
{
  "id": "90cc1b23-9681-40f4-a54b-4c059cd4397d",
  "created_at": "2024-03-04T20:08:48.399442+00:00",
  "action": "entity.onboarding_requirements.updated",
  "api_version": "2024-01-31",
  "entity_id": "ce0e9fc7-b3e7-4f12-ad86-bfb0725a99f0",
  "description": "entity_onboarding_requirements_updated",
  "object": {
    "id": "ce0e9fc7-b3e7-4f12-ad86-bfb0725a99f0"
  },
  "object_type": "entity",
  "webhook_subscription_id": "c7f37127-44e5-494a-833a-21e60585f187"
}
```

#### Earlier versions

```json
{
  "id": "90cc1b23-9681-40f4-a54b-4c059cd4397d",
  "created_at": "2024-03-04T20:08:48.399442+00:00",
  "action": "entity.onboarding_requirements.updated",
  "api_version": "2023-09-01",
  "entity_id": "ce0e9fc7-b3e7-4f12-ad86-bfb0725a99f0",
  "name": "entity_onboarding_requirements_updated",
  "object": null,
  "object_id": "ce0e9fc7-b3e7-4f12-ad86-bfb0725a99f0",
  "object_type": "entity",
  "significance": "medium",
  "webhook_subscription_id": "c7f37127-44e5-494a-833a-21e60585f187"
}
```

> **Info**
>
> For more information on what changes we consider breaking and non-breaking in our API, please refer to our [Versioning policy](/v2024-01-31/api/concepts/versioning#breaking-changes).