We have recently implemented a new method for connecting to our API called ConnectWithToken. To use this method, you need two IDs:

1) An app ID. This ID belongs to the developer and uniquely identifies the app requesting the connection. To obtain an app ID, developers need to sign up for an e-conomic developer agreement. They can then create any number of apps from the ‘Developer’ tab in the agreement, and an app ID will automatically be generated for each app.

To create an app, developers need to enter the name of the app and the required roles. Each role specifies different permissions to access e-conomic data required on part of the user. You can find the full list of entities available for each role on our Roles page.

The ‘Developer’ tab, available in developer agreements

2) An access ID (also called a token). This ID belongs to the e-conomic user who wants to use an app. To obtain an access ID, users must be directed by the app webpage to e-conomic’s Grant access page. This page requires that the app identifies itself using the app ID issued and allows users to enter their login details.

Provided they have sufficient rights corresponding to the roles the app needs, they will then get an access ID which they can return to the developers, either manually or automatically using a URL redirect, to allow their app to connect to the e-conomic API.

e-conomic’s Grant access page where users can grant access to apps

For a complete explanation of the token model, see our connection tutorial.

Benefits with the new model

The benefits with the new model include:

• App access is restricted to the parts of e-conomic that the app user has access to through the GUI
• It is possible to link apps to developers, users, app IDs and access IDs to allow for increased tracking and security
• Developers don’t have to store usernames and passwords of e-conomic users, meaning all security related to sensitive data is handled by e-conomic
• Users can grant/revoke access for individual apps in e-conomic, and when they change their passwords they don’t lose access to all apps as previously
• e-conomic can centrally manage specific apps that misbehave or abuse the system without affecting the users’ other apps

These benefits should be held up against the old method. Here, app access is handled by requiring the user to enter their e-conomic username and password every time they want to use the app, or alternatively the developers need to keep the username and password in a way where they can get the password back in clear text. Of course, allowing third parties such as developers to store e-conomic user credentials is a potential security risk and not a suitable or safe way of protecting user data.

Additionally, the old connection method does not allow for differentiated access levels for what the app can access through the API. This means that even if the app user only has access to a small part of data in e-conomic, the app will be able to access all data in the agreement.

Updates to the new model

We implemented the new connection method to alleviate the problems with the existing method. However, the release of the new connection model has not been entirely free of issues as our first attempt turned out not to be far-reaching enough. In the first version, app IDs were not generated automatically, but simply specified by the developer. This meant that app IDs were not necessarily unique and could thus, intentionally or unintentionally, be mixed up.

Also, without developer agreements, tracking and control with developers, apps and app users was not possible. Therefore, we decided to update and relaunch the connection model, even though this caused breaking changes to the original API.

This was of course unfortunate, but it allowed us to implement an updated version of the new model with much better security and control, which was one of the main goals of replacing the old method in the first place.

Going forward

We intend to remove the old connection method entirely and replace it with the new model, once we believe that the new method has been tweaked and tested sufficiently, and a certain grace period has passed.

So it’s only a matter of time before we will require all app partners to start using the new connection method exclusively. It will be necessary to cut off access to the old connection method completely, since users will otherwise continue to be able to potentially access the API using the old method and thereby get access to more data than they can through the e-conomic GUI.

During the coming months, we would like to improve the following areas:

• Implement additional roles. We will soon add a ‘Bookkeeping’ role (basically corresponding to the ‘Bookkeeping’ tab in e-conomic) to the existing roles of ‘Superuser’, ‘Sales’, and ‘Project employee’.
• The ‘Developer’ tab in developer agreements is very basic and should be expanded in terms of both design and functionality, e.g. allowing developers to see how many users have granted access to each of their apps, how much each user is accessing their apps, etc.

A lot of developers have already started using the new method. Since tracking is much easier with the new method, we can see exactly how many developers have signed up for a developer agreement, how many apps have been created from each agreement, and how many access IDs have been generated for each app.

So far, the usage numbers look very promising, which is also in line with the postive feedback and comments we’ve received from developers.