Changelog

This page contains the changelog of the Moneybird API. You can subscribe to updates via RSS.

  • Changelog 24-03-2024

    • The ledger account GET endpoints now include the linked taxonomy item.
    • The parameter ‘rgs_code’ is now available to the ledger account POST and PATCH endpoints. This parameter is optional for now. IMPORTANT: Creating ledger accounts without taxonomy item is now deprecated. From 01-07-2024 forward it will not longer be possible to create ledger accounts without providing a taxonomy item code based on the RGS standard.

  • Changelog 21-03-2024

    • The API now includes a fresh addition titled SubscriptionTemplates, designed for facilitating online subscription sales. This feature empowers customers by enabling them to independently manage their subscriptions and payment information.
      • The API facilitates accessing SubscriptionTemplates and generating online sales links. These links allow for pre-setting the contact and start date parameters for the subscription.

  • Changelog 10-08-2023

    • Webhooks and objects containing ledger account bookings will now include the corresponding financial_mutation_id
    • Obtainining a single financial mutation is now available via GET /financial_mutations/:id
      • Do not use this endpoint for obtaining multiple financial mutations in a short time frame, as you hit the rate limit very quickly. Use the synchronization endpoints instead.

  • Changelog 27-07-2023

  • Changelog 09-05-2023

  • Changelog 16-12-2022

    • Contact people have been added to recurring sales invoices and subscriptions.

  • Changelog 31-10-2022

  • Changelog 05-09-2022

    • The ‘delivery_method’ Post for the endpoint PATCH /sales_invoices/:id/send_invoice is now deprecated. From 01-01-2023 forward it will no longer be available
    • The field ‘end_to_end_id’ in the response of a purchase_transaction on the endpoint GET /purchase_transactions/get_purchase_transactions is now deprecated and will be replaced with the field description. As of now the ‘description’ field is available so you can make the transition if you use this field.

  • Changelog 12-04-2022

  • Changelog 01-02-2022

    • We’ve added manual_payment_action and linked_payment_id attributes to a Payment object in the API and webhooks. This makes it possible to find out how a payment is linked in the adminsitration.

  • Changelog 23-12-2021

    • We’ve updated the api endpoint GET /contacts/filter to also take contact people into consideration when filtering.

  • Changelog 03-12-2021

  • Changelog 10-08-2021

    We introduced two new fields:

    • recurring_sales_invoice_id: We’ve added the recurring_sales_invoice_id field to any response containing a subscription.
    • subscription: We’ve added the subscription field to any response containing a recurring_sales_invoice.

  • Changelog 29-07-2021

    We’ve added the journal_type field to any response containing a general journal document.

  • Changelog 27-07-2021

    We introduced two new fields for products:

    • identifier: a unique identifier for your products, for example for productnumbers or SKU codes. When products have an identifier, you can find them using the new endpoint: GET /products/identifier/:identifier.
    • title: an extra title for products besides their description. Used in the new checkout feature.

  • Changelog 06-07-2021

    • We’ve added the mandatory tax text to details entities.

  • Changelog 29-06-2021

    • We’ve made it possible to filter results from the GET /tax_rates endpoint. You can filter on important attributes of a tax rate, such as name, country and percentage.

  • Changelog 20-04-2021

  • Changelog 13-01-2021

    • We’ve added a new filter endpoint for contacts. you can find these and the possible filter options at GET /contacts/filter

    • The GET /contacts/synchronization endpoint also includes these filter options. You can filter on created_after, updated_after, first_name and last_name.

  • Changelog 27-10-2020

  • Changelog 26-08-2020

  • Changelog 11-08-2020

    • We’ve added the ledger_account_id to a payment entity, so it is now clear to which ledger account a payment is booked on. This applies to payments registered to all document types, sales invoices and external sales invoices.
    • We’ve added the option to select a payment method when registering a payment.

  • Changelog 15-07-2020

  • Changelog 06-07-2020

  • Changelog 23-06-2020

  • Changelog 03-06-2020

  • Changelog 08-04-2020

  • Changelog 03-03-2020

    • We’ve added extra rate-limit headers when the request is throttled. See throttling for an explanation of the contents of those headers.

  • Changelog 26-02-2020

  • Changelog 15-01-2020

  • Changelog 25-11-2019

    • External sales invoices will now be created with state ‘open’ instead of ‘new’. This is consistent with the create endpoints for sales invoices and documents.

  • Changelog 19-11-2019

    • We have added a transaction_identifier field to payments. This allows you to store the identifier of a Payment Service Provider transaction. If you use Mollie for payments, the identifier will be used to automatically link the payments to the pay out of Mollie on your bank account.

  • Changelog 14-11-2019

  • Changelog 13-11-2019

  • Changelog 22-10-2019

    • We officially support PDF downloads of sales invoices and estimates through a new API endpoint called “download_pdf”. The users that are currently using an unofficial workaround should migrate to the new endpoints by the end of this year.

  • Changelog 30-09-2019

    • From December 1st onward, sending invoices and estimates will no longer be possible if the email address in the sending address has not been verified. Read more about this in our blog. The resulting http statuscode when trying to send without a verified sending addresses will be 400, with the in the body the error message “sending address not verified”.

  • Changelog 09-08-2019

    • The custom_fields_attributes and details_attributes fields are now all consistent with each other. This simplifies the mapping of there between different endpoints. It has changed from custom_fields_attributes[*][id] to custom_fields_attributes[id].

  • Changelog 08-08-2019

    • Webhooks now have a unique secret key, given in the ‘token’ field on creation. This token is also given with each webhook call in the ‘webhook_token’ field. It can be used to verify that the webhook call comes from Moneybird.

  • Changelog 17-07-2019

    • We reversed the July 4th change because it was causing a lot of trouble for developers. We will again return the URL for viewing the invoice online, even though users won’t be able to use it until the invoice has been sent. We have updated the documentation for sales invoices to clarify the existing behaviour.

  • Changelog 04-07-2019

    • When retrieving a sales invoice object the url field will be empty as long as the sales invoice has not been sent, as the url is unreachable when the invoice is not sent. When sending the invoice through the api the url will be returned.

  • Changelog 21-05-2019

    • Instead of responding with only 200 we now return the resulting object data on sending sales invoices or estimates through the /sales_invoices/:id/send_invoice and /estimates/:id/send_estimate endpoints.

  • Changelog 06-03-2019

    On April 3th a change to the api will be made.

    • When creating a new contact without specifying a value for email_ubl, the email UBL attachment setting from the administration will be used instead of a default value of true. The value for sending UBL attachment can be set in Moneybird via Settings > Simplerinvoicing & UBL > UBL as e-mail attachment. By default this value is set to true.

  • Changelog 24-08-2018

    On October 24th some changes to the api will be made.

    • When making a recurring sales invoice or an estimate, it is possible to enter a workflow via the ‘workflow_id’ field. If this field is not entered, the default workflow from the administration will be used. This is inconsistent with the behaviour on our website and app, there the default invoice- and estimate-workflow of the contact will be chosen first. If the contact doesn’t have a default workflow, the default workflow from the administration will be chosen after all. To make consistent behaviour, we will also implement this behavior in the API.
    • Recently we added a public view code to your sales invoices and estimates. Sales invoices end estimates are only visible for the recipient when they provide this code. So far the use of this code was not needed for invoices and estimates created by the API, but this will change. If you use the API to point you clients to their invoices using the ‘url’ field, you should also provide the public view code for security. New sales invoices and estimates return a ‘public_view_code’ in the API payload. For old sales invoices and estimates, clients can use the invoice or estimate id.

  • Changelog 11-07-2018

    • Sales invoices and estimates are now only visible for the recipient when they provide an public view code. If you use the API to point your clients to their invoices online using the url field, you should also provide the public view code for security. New sales invoices and estimates now return a public_view_code in the API payload. For old sales invoices and estimates, clients can use the invoice or estimate id to view the document.

  • Changelog 16-01-2018

    • Because of new tax regulations, it is no longer possible to specify a book_method when marking a sales invoice as uncollectible. All uncollectible invoices will be booked as uncollectible revenue from now on.

  • Changelog 15-08-2017

    • We fixed a bug that allowed payments to be registered for draft sales invoices. An invoice has to have been sent before payments can be registered.

  • Changelog 12-07-2017

    • We have added the field tax_number_valid to the contacts entity.

  • Changelog 28-06-2017

    • We have added an endpoint to change the state of an estimate /estimates/:id/change_state
    • Added an endopint to bill an estimate /estimates/:id/bill_estimate

    See the Estimates documentation for more information.

  • Changelog 27-03-2017

    We’ve extended the functionality of webhooks by adding the possibility to subscribe to events. You can now choose which events you would like to recieve a notification from, by adding an array with the names of the events to the data. See webhooks for more information.

    If you decide to not subscribe to any events the old implementation will be used (notifications after state changes of sales invoices). This is to prevent existing webhooks from failing.

  • Changelog 18-11-2016

    Webhooks now return our long integer IDs as strings to avoid issues with JSON parsing tools. The API was already doing this as well.

  • Changelog 26-10-2016

    • All lists of entities are now equipped with pagination. Use the page and per_page arguments to control the pagination. A response contains a Link header with a next and prev link. Read more about pagination.

  • Changelog 13-10-2016

    • Filtering can now be used when listing recurring sales invoices. A sync API has also been implemented for recurring sales invoices. See the recurring sales invoices documentation for more information.

  • Changelog 12-10-2016

    • Assigning a nonexistent custom field to a contact, estimate, (recurring) sales invoice or identity now returns a 404 HTTP response with a helpful error message instead of a generic 500 error.
    • In many error cases the error response hash now also contains a symbolic entry with machine readable error details. See the documentation for an example.

  • Changelog 18-08-2016

    • After deleting an entity, the API will now return a 204 No content response without a body. This conforms to the RFC2616 standards.

  • Changelog 28-07-2016

    • All entities that belong to a specific administration now return their administration_id field in API responses.
    • The contact list now returns the documented 100 contacts, instead of 50.
    • Documentation has been improved for SalesInvoice and Estimate filtering.
    • Deleting a contact will now return a 422 HTTP code when deleting failed. Deleting can fail when a contact is still used within the bookkeeping.

  • Changelog 23-03-2016

    • Documents now include a nested representation of the contact they’re atttached to.
    • The events attribute was added to a lot of entities. These events represent the history items shown in the MoneyBird web interface. For example, an event containing action: sales_invoice_send_email will tell you the time at which an invoice was sent by email and to whom it was sent.

  • Changelog 10-03-2016

    When creating a sales_invoice without giving a workflow id, MoneyBird will try to find a default invoice id saved at the contact first before using the administration default.

    It’s no longer possible to use the email attribute when creating or updating contacts. You’ll need to use the send_invoices_to_email and send_estimates_to_email attributes instead.

    It’s no longer possible to use the attention attribute when creating or updating contacts. You’ll need to use the send_invoices_to_attention and send_estimates_to_attention attributes instead.

  • Changelog 24-11-2015

    Many JSON parsing tools out of the box don’t work well with our long integer IDs. Therefore we’ve updated the API to always return these IDs as strings instead.

  • Changelog 10-11-2015

    We’ve added an /estimates endpoint to manage estimates. It includes all functions from the old API, and several new ones. It has been developed to be consistent with /sales_invoices. Read more in the estimates API documentation.

    A due_date attribute has been added to sales invoices. This attribute also exists for estimates.

  • Changelog 19-10-2015

  • Changelog 14-10-2015

  • Changelog 02-10-2015

    We have improved the management of API tokens and OAuth applications. On the new developer page in your user account, you can find:

    • Register new OAuth applications for external applications
    • Register a personal OAuth API token for personal user
    • Subscribe to our API newsletter to keep informed about API changes

  • Changelog 23-03-2015

    The send_method attribute on contacts has been replaced by the delivery_method attribute. The possible values are also slightly different:

    Email
    Send invoices to contact via email.
    Post
    Send invoices to contact via postal system.
    Manual
    Just mark invoices send to contact as sent.

  • Changelog 25-02-2015

    We have added a new webhook feature to the API. More information is available in the documentation.

  • Changelog 05-02-2015

    The timeline scope for authentication is removed from our application. An update to your authentication process is needed to enforce the new default scope sales_invoices. This should be an one-time change.

  • Changelog 07-01-2015

    We have extended the API with an endpoint for import mappings. With the move from the old MoneyBird to the new MoneyBird, all ids of entities in an administration have changed. Some API developers might have saved old ids in their database. In order for them to keep querying our API with the right ids, we have added an API for the import mappings. By querying the import mapping API, you can transform old ids to new ids in the new MoneyBird. This should be a one-time conversion, the import mapping endpoint will not be indefinitely available.

    Old ids can be recognized as plain autoincrement ids, usually not larger than 1.000.000. The ids in the new MoneyBird are no longer autoincrement ids, but are defined based on the time of generation in our database. The ids are therefore much longer, an example of a new id is 111433428396672003. Make sure your application can handle these large numbers, sometimes this requires a change to your database structure or changes in JavaScript.

  • Changelog 26-11-2014

    We have launched a new API for the new MoneyBird. All functions of our old API can be found in the new API. Some REST endpoints have been renamed to reflect the new MoneyBird better.

    The new API is still a REST API and behaves in a comparable way as our previous API.

    Common

    • HTTP Basic authentication is removed, authentication can only be done with OAuth keys. More information
    • JSON is the default data type for all requests and responses. XML is still available by changing the format in the path.
    • The API can be found on https://moneybird.com/api, versioning is done in the URL. The new API has version v2.
    • Subdomains for accessing certain administations are removed. The path to a resource contains the id of an administration: /api/v2/:administration_id.json
    • All primary keys of entities in the API are bigints, for example 107693607045039116. Storing these ids in your own database might need special attention.
    • All entities formerly present in the database will have a new primary key. When you have stored ids of entities in your own database, you need to migrate these.

    Sales invoices

    • Renamed endpoint from /invoices to /sales_invoices
    • The endpoints for the synchronisation API have been renamed from /sync_list_ids and /sync_fetch_ids to /sales_invoices/synchronization. The HTTP method makes the difference between listing and fetching.
    • Changing contact information or adding contacts through the sales invoices endpoints is removed. Upon creation of a new sales invoice, a contact should be provided. This contact needs to be created with the contact endpoints.
    • The attribute description has been renamed to payment_conditions
    • The attribute po-number has been renamed to reference
    • The attribute recurring-template-id has been renamed to recurring_sales_invoice_id
    • The attribute sepa-active is removed, the workflow now defines the payment process of the sales invoice
    • The attribute invoice-profile-id is removed. Invoice profiles have been replaced by document styles and workflows. A document style determines the layout of the sales invoice, the workflow determines the process for receiving a payment. Both can be set by document_style_id and workflow_id.
    • Payments for sales invoices no longer store a payment method. The method of payment is determined based on the financial mutation the payment is linked to.

    Documents

    Recurring invoices

    • The /recurring_templates endpoints have been removed in favor of /recurring_sales_invoices.
    • The attribute frequency-type now accepts strings describing the frequency. Integer values are not accepted anymore.
    • The attribute invoice-profile-id has been removed in favor of a document_style_id and workflow_id.

    Contacts

    • The endpoints for the synchronisation API have been renamed from /sync_list_ids and /sync_fetch_ids to /contacts/synchronization. The HTTP method makes the difference between listing and fetching.

    Invoice profiles