API updates on SOAP and REST

August 5, 2015
Dear e-conomic developer,

Welcome to the latest edition of the e-conomic developer newsletter. Below you can learn about app identifiers, check out what we are working on, get updated on our SDK and see the latest REST features.
App Identifier

App Identifier now required (Important!)

Many of our SOAP API integration partners do not provide a valid custom user agent, which makes it very hard for us to contact these integration partners in case we encounter problems. In order to offer better support for your integrations, the following will apply:

From
November 16th 2015 we require that all SOAP API requests include a valid X-EconomicAppIdentifier header. From this date we will start rejecting all requests made by your app, if you do not include this header.

Read more
here.
Working

What we are working on

Our efforts in Q2 focused on supporting sales invoicing and the related endpoints in our REST API. This continues to be the focus area for Q3 and Q4. Up until now, we've wrapped up:

/invoices-experimental/drafts
/layout
/unit
/payment-terms


We're also close to getting a new "totals" endpoint ready for sales invoices. Stay tuned for info on this on our
Twitter account and on our TechTalk blog.

Over the next months we'll continue to add functionality for booking of the new draft invoice and exposing booked invoices in its new signature. The goal is to have invoices-experimental/* wrapped up and ready for production consumption in Q3.

Immediately after that we'll continue to work on the related endpoints, such as customers and products. In summary, the current order of work is:


/invoices-experimental/totals (GET)
/invoices-experimental/booked (GET)
/invoices-experimental/booked (POST, i.e., the booking method)
/customers/* (CRUD)
/products/* (CRUD)


As soon as any of the above is implemented, we'll be sure to tell you about it on our
Twitter account and on our TechTalk blog.
SDK

SDK update & deprecation

When we first decided to provide an e-conomic API for our integration partners, it became apparent to us that we also needed to offer a much easier solution for setting up a connection to our SOAP API. So we created an SDK that wrapped all access and communication with our SOAP API in an easy-to-use .NET assembly.

Times change and so does what is included in a framework. Communication with a SOAP web service is much easier now than it was when we first set out, so the need for such an SDK is no longer as apparent. Furthermore, while using the SDK is easy, it unfortunately also creates an abstraction that hides what really goes on.

This results in integrations that risk unknowingly using our API in less than ideal ways when it comes to, for example, the use of network bandwidth, with poor performance as a result.

The much better tooling available, when integrating with SOAP services, combined with the development of our new REST API means that we will no longer maintain our SDK. The current release (v1.4.18) which was released on May 6th 2015 is the last release of the SDK.

From this date the SDK has been deprecated and we no longer advise the use of this SDK. We will no longer actively maintain this SDK and it is no longer supported.

Read more
here.
App settings

New REST feature - /app-settings

We’ve had a lot of requests from app partners for a settings storage exposed through the REST API. This feature is now exposed at /app-settings and is ready for production purposes. You now have a place to store user preferences and default settings for your integration.

The /app-settings endpoint allows apps to save settings specific to the app through the API as custom key/value pairs. The settings are naturally specific to the individual apps and are not accessible for any other integrations.

Read more
here.
Receipts

New REST feature - Attachments to vouchers in REST API

Bookkeeping can be done in a myriad of ways. In Denmark we’re embedded in the ‘journal’ / ‘daybook’ way of registering our bookkeeping entries. Other countries are more prone to the ‘ledger’ approach. In e-conomic we support both of these two main entry methods. We call them Standard Journal and International Ledger.

From an API point of view, each method should be approached differently. The Standard Journal is mainly supported via our SOAP API, although some data is also exposed in REST via GETs only. International Ledger is only supported in the REST API and is currently only in play on Swedish and Spanish agreement types.

As the latest addition to the REST API, you’re now able to GET, POST, PUT and DELETE attachments on vouchers. This enables you to build integrations with e-conomic that can create, edit and delete the documentation on vouchers.

Obvious use cases for this could be registration of expense receipts or adding documentation for a supplier invoice.

Read more
here.

Web hooks explained

We often get questions on how to configure web hooks on an agreement. So we've brushed up the documentation and moved it to the developer portal.

Check it out
here.

Best regards,
Your e-conomic API Team