API on Desktop Edition

I am starting to begin an API integration on the desktop edition. This is working for reasons I can explain to an admin privately, but from reading other posts here I see that it maybe isn’t supposed to work.

Is use of the API something that is prohibited by the desktop license, or will be disabled in some future version? If so, I do not want to spend a lot of effort with integration. I do expect that we will be ready for cloud or server edition someday, but currently we are quite small and not there yet.

No it isn’t prohibited

There’s no plan to discontinue the API for the desktop edition, however, the access to the API is currently based on a “hack”–for lack of a better word.

For security reasons, the API requires an administrator account with a password and this feature isn’t available for the Desktop edition so accessing the API requires creating an admin account in the Server edition and using that to access the API.

Will this “hack” be available in future version, no one knows so no guarantees for the Desktop edition.

Thank you! Yes, I originally tried the server edition and so had a user in place to use for the login. I did not want to provide the details in case it should not be done.

I appreciate that it is not officially supported. If it stops being supported, I can consider whether to stay on an old version or upgrade to server/cloud edition.

I’m not using the API, because I can’t seem to find where a lot of functionality resides (importing mt940 files, bulk-inserting declarations and invoices), and many of the reports are simply not available (balance sheet, etc.) The objects are, but the results aren’t

Because of that, I’m using screenscraping / http posts to fill in forms and click links, but that doesn’t work with recent versions.

Is there any guidance on these specific calls?

btw, I have both desktop and a server version (to support you guys).

Were you relying on the old urls? I say this because the new urls are no longer guessable.

Yeah the urls were structured. I tried to use screen scraping as an alternative, but it’s just too much work. It seems things are deliberately hidden / obfuscated and it’s just a pain
. Very annoying because the API is undocumented and doesn’t do most important things I want automated (bulk inserts / uploads, collect all reports of a specific period in one big excel (1 sheet per report)).

1 Like

Bulk insert / upload is possible with the API, but you have to write it yourself…

It would be great if the API, with each Result object, provided the URL for the user-facing URL for the corresponding object. That way you could at least automatically open the report for the user to click copy, etc. (Or use a headless Chrome browser / Electron app to do it for you…)

I decoded the new URL, which are base64-encoded protobuf, but relying on that seems a very brittle way to proceed. For now I have to manually open the report and click Copy and paste it into the app for processing. Not ideal, but it gets the job done.

1 Like

I’m not sure why this feature was removed or if there’s going to be an alternative for it.

I too thought appending .json to the URL was a great feature to have since it checked all of the following boxes:

  1. Restricted users could use it without need for an admin password. This in itself solves many security problems.

  2. Retreival of data is much faster and more efficient than using the backend API. It’s just as costly as visiting the webpage. I was mostly using this to get transactions data.

  3. It reduced the work of reporting to a single click of a button: click, report gets created, get the uuid back, build the url and share just that.

Anyway, @isotherm request seems very reasonable since it should solve part of the issue here.

Also, there’s this other idea for querying of full reports:

As for restricted users, this could be the solution:

I think these three additions would be as good as the previous setup.

I’d have to create my own MT940 parser, somehow make sure I can do multiple inserts / updates in one transaction, which isn’t possible, and I’d have re-create all the reports.
So basically I’d be re-implementing everything except for a basic ledger model + some crud screens. At that point it’d be less frustrating to create my own software.

I’m really not interested in clicking all these reports. It’s error prone, and my current solution works.

My usecase isn’t all that obscure. At the end of the year, I want a (proper) Excel document where there’s a sheet for: balance, P/L, assets, bank transactions, etc. And all of this is re-created every year for the same fiscal period.

With proper document I mean numbers are numbers, every piece of data has its own cell, etc. Creating a document by hand takes about 2 hours of creating reporting entries per entity, copy/pasting, converting the comma / decimals / tabs, fixing mistakes etc.

So I’m still using a 6+month old version, and refuse to migrate. I actually did migrate before, but restored both data and app from backup as I’m unable to do this anymore

I have just updated the manager_api Python module to v0.1.2. One change is the ability to get the user-facing URL for an object. This means that once a report is created, you can automatically display it to the user in a browser.

Currently, only viewing objects is supported, but in theory it can generate more kinds of URLs. Batch insert/update URL could be generated (already can, perhaps, but I didn’t research it) and then post your uploaded file to that URL. I suppose the disadvantage is that it’s not a documented API endpoint, so the syntax could change later.

I understand your frustration. I am unaffiliated developer just providing this module on my own time, so perhaps it can help you or others.

1 Like