Release notes

Stay up to date with the latest features, improvements, and breaking changes in the current version of Monite API.

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.

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/: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/:id endpoints.
    • The request payloads of the POST /receivables and PATCH /receivables/: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/: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.

Changelog

October 4, 2024

Accounts Payable

  • Payable improvements:

    • Deleting payables. Payables in any status can now be deleted by using the new DELETE /payables/{payable_id} endpoint. Entity users need the payable.delete permission to be able to delete payables. Successful deletion of a payable triggers the payable.deleted webhook.

    • Improved search. We’ve improved search and filter parameters in GET /payables and GET /payables/analytics:

      • New search_text parameter lets you perform partial, case-insensitive search across multiple text fields of a payable at the same time. Currently it searches in counterpart names and document numbers (document_id).
      • Added the counterpart_name__contains and counterpart_name__icontains for searching by partial counterpart name in the case-sensitive and case-insensitive modes, respectively.
    • Payables have a new read-only field created_by_role_id that indicates the role of the entity user who created this payable.

    • Projects and tags can now be updated for payables in any status.

  • Purchase order improvements:

    • The entity_vat_id_id field is now optional in purchase orders and can also be unset (that is, changed to null).
    • Updated PDF templates for purchase orders. Added the “Supplier” block and updated some labels for improved clarity.
  • Approval policy improvement:

    • Projects can now be used in approval policy conditions. For this, the invoice.project_id attribute must be added to the trigger object. See an example.

Accounting integration improvements

We’ve added new endpoints to list invoices and payables (bills) that exist in the entity’s connected accounting system without pulling those documents into Monite. Monite partners can use these endpoints to implement custom document comparison and synchronization logic.

September 30, 2024

Accounts receivable document history

Monite now keeps a record of all changes made to each invoice, quote, and credit notes, from document creation to the final status. This provides entities with an overview of how a document has evolved over time. For example, entity users can see the following:

  • all revisions made to an individual invoice, quote, or credit note before it was sent to the client,
  • who made a change and when,
  • when a particular status transition occurred (for example, when a quote was signed),
  • payments made towards an invoice,
  • emails sent to the clients and the recipient email addresses,
  • and more.

To access a document’s history, use the following endpoints:

History can be filtered by the date range or event type, allowing users to narrow the results or find a specific entry.

Change history data is available only for changes made since September 30, 2024.

September 4, 2024

General

  • Projects. Users can now aggregate and track payables and receivables under the same work scope as a project via the new /projects endpoints. See more.
    • New create, read, update, and delete permissions for the project object.
    • New webhooks for the created, deleted, and updated events of projects.
    • Payables and receivables can be filtered by project via the new project_id query parameter in the GET /payables and GET /receivables endpoints.

Accounts Payable

  • Payable analytics. Use the new GET /payables/analytics endpoint to get the total number and sum total amount of all existing payables, along with the breakdown per payable status. Results can be narrowed down to a specific time period, counterpart, or other search filters. See more.
  • Find and filter payables by tags. The GET /payables endpoint has a new query parameter tag_ids to find payables that have any of the specified tags.

Accounts Receivable

We’ve added a few improvements to paid invoices:

  • Paid invoices can now be sent via email.
  • Added a new entity setting generate_paid_invoice_pdf. If it is set to true, the PDF version of paid invoices will indicate that the invoice is already paid. The PDF file gets regenerated at the moment when an invoice becomes paid. It is not issued as a separate document and the original PDF invoice is no longer available.
  • Added a new email template receivables_paid_invoice that is used when sending paid invoices. It is similar to the receivables_invoice template used for unpaid invoices but does not include the Pay invoice link.

Other

  • Added the last_updated_at field to the responses from the /mailbox_domains endpoints.

August 29, 2024

General

August 23, 2024

Accounts Receivable

  • Tags for receivables. Invoices, quotes, and credit notes can now have tags (labels) assigned to them. You can also find and filter these documents by tags by using the tag_ids__in query parameter of the GET /receivables endpoint.

  • Invoice payment date. Invoice responses include the new paid_at field that indicates the date and time when the invoice was fully paid. When using accounts receivable together with Monite payment rails, the paid_at timestamp is filled in automatically when counterparts pay invoices. If you use external payment rails, the paid_at timestamp is taken from the corresponding field provided in the POST /payment_records or POST /receivables/{invoice_id}/mark_as_paid request.

    • Added a new optional request field paid_at to POST /receivables/{invoice_id}/mark_as_paid. If omitted, it defaults to the date and time of the request.
  • Previously, recurring invoice schedules could only be extended. Now they can also be shortened - as long as the new end date is still a future date.

August 21, 2024

Accounts Receivable

  • New entity setting vat_mode controls whether new invoices and quotes use VAT-exclusive pricing (default) or VAT-inclusive pricing. This can be overridden on the document level by providing the vat_mode field when creating invoices and quotes.

August 15, 2024

General

  • Tags for counterparts. Counterparts can now have tags (labels) assigned to them. You can also find and filter counterparts by tags by using the tag_ids__in query parameter of the GET /counterparts endpoint.

Accounts Receivable

  • Support for VAT-inclusive prices. Use the vat_mode field of invoices and quotes to specify whether product prices include or exclude VAT. In case of VAT-inclusive pricing, Monite will calculate the taxable base price by subtracting the VAT rate from the product price.

    Line item data in API responses includes both VAT-inclusive and VAT-exclusive prices calculated based on the original product price and the chosen vat_mode:

    • line_items[].product.price - price before VAT
    • line_items[].product.price_after_vat - price with VAT

    Note: after an invoice or quote is created, its vat_mode cannot be changed, event in draft documents.

  • Multi-branding enhancements. We’ve expanded the ability to change entity branding information (email, logo, phone, and website) for accounts receivable documents:

    • Branding information can now be changed not only for invoices, but also for quotes and credit notes.
    • Previously, entity branding information could be changed only for existing documents via PATCH /receivables/{receivable_id}. Now you can also specify this information directly during document creation - by providing the entity object in the POST /receivables request.

August 7, 2024

Payments

  • Search and filter payment intents. Use the new GET /payment_intents endpoint to get a list of all payment intents created for an entity. Optionally, you can provide the object_id query parameter to find intents associated with a specific accounts payable or accounts receivable invoice: GET /payment_intents?object_id=INVOICE_ID.

    Among other things, this lets you:

July 31, 2024

Accounts Receivable

  • Create invoices and quotes with inline products. Entities can now specify the product details for line items—name, price, and other attributes—directly in the request payload without having to create a product catalog in advance. This is useful for one-off invoices or if the entity’s product catalog is maintained outside of the Monite platform. Invoices and quotes can also use a mix of inline and catalog products if needed.

  • Digital quote signing. Entities can now require that their customers (counterparts) provide a signature when accepting quotes. If the quote field signature_required is true, the counterpart’s representative needs to provide their name, email address, and signature image to accept the quote.

    After the quote is accepted, its PDF file is updated to display the customer signature.

    Entity setting quote_signature_required controls the signature requirement for newly created quotes. This can be changed at the quote level via the signature_required field.

Accounts Payable

  • New query parameter id__in in GET /tags to bulk fetch multiple tags by their IDs.

July 17, 2024

Accounts Payable

Accounts Receivable

  • New response fields — file_language and original_file_language — in quotes, invoices, and credit notes. These fields indicate the counterpart’s and entity’s language for the PDF, respectively.

Accounting integration

  • Removed the /accounting_sync_rules endpoints that were used to customize invoice and payable statuses to push to an accounting system.
  • New endpoints for accounting integration:
    • The /accounting_synced_records endpoints to retrieve or push records of synchronizations between Monite’s database and the entity’s accounting system.
    • The /accounting_tax_rates to get tax rate from the accounting system.

July 3, 2024

General

  • New supported country codes:
    • BL - Saint Barthélemy
    • BQ - Caribbean Netherlands
    • CW - Curaçao
    • MF - Saint Martin (French part)
    • SX - Sint Maarten (Dutch part)
  • Entity field address.state is now required for US entities that wish to use Monite payment rails.

Accounts Payable

  • Payable OCR auto-tagging. Entities have a new setting payables_ocr_auto_tagging to specify the tags that will be automatically assigned to new payables created via OCR. For details, see Tags auto-assignment.
  • New paid_at field was added to the payable responses. It contains the date and time when the payable was moved to the paid status.

Accounts Receivable

  • Invoicing across multiple brands. Entities that have multiple brands can specify the business email, logo, phone, and website to be displayed on each invoice, if these values need to be different from the entity’s defaults. The data can be provided in the invoice.entity object in the invoice update request, for example:

    PATCH /receivables/{invoice_id}
    {
    "invoice": {
    "entity": {
    "website": "https://example.com",
    "logo": "https://example.com/another-logo.png"
    }
    }
    }
  • More flexible reminder configuration. Invoice payment reminders and overdue reminders can now be initially created without any terms, and the terms can be added any time later prior to issuing the invoice.

  • Email localization improvements:

    • The language field in POST /receivables/{receivable_id}/send requests has been deprecated. Instead, use the counterpart’s language field to specify the preferred language for emails and documents that will be sent to that counterpart.
    • Also, if the language parameter is omitted in /send requests, the email language now defaults to the counterpart language instead of English.
  • Partner metadata can now also be updated for non-draft invoices, quotes, and credit notes.

June 19, 2024

  • CC and BCC in receivables email. Added the ability to include a list of email addresses using the recipients field in the payload the /receivables/:id/send and /receivables/:id/send_test_reminders endpoints. Using this field, entities can include email addresses to which they want to send a copy or a blind copy of the email.
  • Displaying company trade name in documents. Invoices, quotes, and credit notes have the new trade_name field that entities can use to specify their trade name, also known as “doing business as” (DBA) or “operating as” (o/a) name. The assigned trade name will appear alongside the entity’s legal name in PDF invoices, quotes, and credit notes created by the entity.
  • Enhanced sorting of receivables. The GET /receivables endpoint has got additional options for the sort parameter. You can now also sort receivables by the created_at, document_id, due_date, or issue_date values.
  • The measure_unit_id field is no longer required to create products for receivables.
  • New id__in query parameter on the GET /products and GET /receivables endpoints lets you bulk fetch multiple products or receivables by their IDs.

June 5, 2024

  • New name__in query parameter in GET /tags.
  • Payable tags have two new optional fields: category and description.
  • Partner setting payable.enable_line_items has been deprecated.

May 22, 2024

  • Automatic matching of purchase orders with payables. Every time a payable is created or updated, Monite automatically tries to link this payable to its corresponding purchase order, which is already created in the system. For such cases, the field purchase_order_id was added to the payable object. To configure this behavior, the field allow_purchase_order_autolinking (default value equals to true) was added to the entity settings.
  • Added a new original_file_url field in responses for invoices, quotes, and credit notes that returns the receivables PDF in the entity’s language. The field was also added to the response of the GET /receivables/{receivable_id}/pdf_link endpoint.

May 8, 2024

  • Document number customization. We added the ability to customize the document numbers for all document types. This customization is done directly via entity settings. For more information, see Document number customization.

April 11, 2024

  • Payment intents can now transition to the refunded status from the payout_failed and payout_cancelled statuses.

April 2, 2024

  • Searching payables by invoice number. GET /payables has new optional query parameters to search and filter Accounts Payable invoices (payables) by their invoice number: document_id__contains (case-sensitive “contains”), document_id__icontains (case-insensitive “contains”).
  • Customizing the required fields for payables. You can now control which fields must be filled in a draft payable before it can transition to the new status. The following endpoints were added for this purpose:
  • Testing reminders for a specific invoice. Use the new endpoint POST /receivables/{receivable_id}/send_test_reminder to send test email reminders (payment reminders or overdue reminders) for a specific Accounts Receivable invoice. For more information, see Manually trigger payment reminders.
  • Verifying invoice reminder configuration. The response from POST /receivables/{receivable_id}/verify contains the new warnings.payment_reminders field that indicates issues with payment reminders configured for the specified invoice. Misconfigured reminders do not block the ability to issue the invoice, but can result in reminders not being sent. Users are advised to fix the reminder configuration issues before issuing invoices.
  • GET /vat_rates has a new optional query parameter counterpart_address_id to filter the applicable VAT rates based on the specified counterpart address in case the counterpart has several addresses.
  • Updated the supported country codes:
    • Replaced CS (Serbia and Montenegro) with ME (Montenegro) and RS (Serbia).
    • Added SS (South Sudan)

March 18, 2024

API version 2024-01-31 is now publicly available to all Monite partners to use in beta. To start using this version:

  1. Change the api_version setting in your partner settings (/settings) to 2024-01-31:

    1curl -X PATCH 'https://api.sandbox.monite.com/v1/settings' \
    2 -H 'X-Monite-Version: 2024-01-31' \
    3 -H 'Authorization: Bearer YOURT_PARTNER_TOKEN' \
    4 -H 'Content-Type: application/json' \
    5 -d '{"api_version": "2024-01-31"}'
  2. Change the X-Monite-Version header value in all API calls to 2024-01-31. For example:

    1curl -X GET 'https://api.sandbox.monite.com/v1/entities' \
    2 -H 'X-Monite-Version: 2024-01-31' \
    3 -H 'Authorization: Bearer ACCESS_TOKEN'

For more information, see How to upgrade.