Our /customers endpoint has moved from experimental to stable. This means that /customers is fully verified for production purposes. We might add more properties to this endpoint along the way, but the basic signature will not change.

With customers being stable and the migration to the new /invoices endpoint, we now allow you to perform all the operations required for creating, handling and booking invoices using REST.

The changes to customers may affect your integration if you’re directly addressing customerNumber or customerContactNumber.

Changes to /customers

Customer Numbers

Our REST API now respects the “customers” flag in All settings -> Categories and units -> Change of numbers in the e-conomic web interface, allowing you to change a customer’s customerNumber in an update operation. To do this, you specify the new customerNumber in the supplied data and do your PUT operation on the original customerNumber.

Customer Contacts

We have changed the customerContactNumber property to contain a different (unique) value. Previously we used the customer contact number displayed in the e-conomic web interface as our customerContactNumber, but that number was only unique within a customer. This number is now displayed in the sortKey property instead.

The following operations on customer contacts have been added:

Delivery Locations

A new /delivery-locations endpoint has been added under /customers with the following operations available:

Totals

We have added a new convenience link on the /customers endpoint allowing you to get the totals endpoint for a specific customer:

Documentation

You can find the full documentation for the /customers endpoint here.

Changes to /customer-groups

The /customer-groups endpoint now has the full CRUD (Create, Read, Update and Delete) range of operations. This means that you can perform the following operations:

Documentation

The /customer-groups endpoint is documented here.

Validation

When creating or updating a customer or a customer group, the REST API will perform a validation of the supplied data before the create/update operation is executed. If any errors are found in the supplied data the operation will not be accepted and you will get a 400 Bad Request response back that includes a list of all the errors found.

The format of this error response is described in our annotated error documentation.