0.0.103 beta available - introduces an API!August 8, 2019 at 7:39pm
I'm happy to finally introduce an API to Actual. I'm still working on docs, but for now it's pretty easy to read the code and play with examples.
To use it, download and run the beta from here:
macOS: https://static.actualbudget.com/Actual-0.0.103.dmg Windows: https://static.actualbudget.com/Actual-Setup-0.0.103.exe
This build will not use your existing data. It will read from
Actualjust in case something goes wrong. You can copy your existing budget in the the
Actual-betafolder if you want to play with it.
Then, install the node client:
/api. Write some code that uses this API: https://github.com/actualbudget/node-api/blob/master/api.js
You can run it by using
budgetIdis the budget id (found in settings) and
funcis the code to run.
Important: Actual needs to be running before running your script. It will connect to the running instance and you will see updates live.
Also, I'm excited to open-source the YNAB4 importer: https://github.com/actualbudget/import-ynab4. This is fully built on top of the new API. Now we can all work together to improve the importers.
Let me know if you have any questions about it!
September 13, 2019 at 2:51pm
This is what got me to finally try out Actual :)
I downloaded transaction exports from my bank accounts and wrote some quick&dirty import scripts (they all provide only CSV). Overall I'm pretty happy with my results so far, and the UX of the app is very pleasant.
- Having to reverse engineer the object shapes to send was a bit of a hurdle, but I assume documentation would come after some stabilization. Before full-on docs, a comment containing an example for common methods would be nice (...or types, I <3 TypeScript).
- I managed at least once to import transactions with invalid dates, which caused an
[ERROR] InternalError: fromDateRepr not passed a number: nullwhen trying to read them back. I ended up just deleting that account and re-importing.
runImportmethod never seemed to work for me, but this might have been because of the invalid data. I wasn't sure what the benefit to me would be for wrapping things in
runImport... maybe a single undo step or something?
More general feedback:
- I mapped the sender/receiver names from my bank data to payees and the transaction comments to the notes field. This was convenient and made categorizing most transactions pretty simple, but has a distinctly messy look. It would be nice to store these raw values in some metadata field(s) and only use them for matching to a manually created payees list.
- I would love to apply the newly selected category for a payee to all transactions of that payee OR have some way to set the category/payee for multiple transactions at a time.
September 14, 2019 at 8:10am
September 20, 2019 at 7:48pm
yep! definitely need docs, and that's going to be included in the site update. example:
dates should definitely be required (and it should error). I know it's been a little while, but do you remember anything about the context in which it happened? using spit transactions, or anything else?
runImportis very different: it's for importing your entire data from somewhere else. it will always create a fresh blank file, and allow to dump a lot of data into it, and then it will "finish" the import and cleanup in a few various ways
if you want to just import transactions, use
September 21, 2019 at 7:13am
I didn't see your second message - that already exists! it's the
imported_idfield and is already used for that purpose when automatically downloading transactions from your bank (a soon to be released feature)
here are all the transaction fields with notes:
September 22, 2019 at 8:24am