iOS Shortcuts for Firefly III

I built a couple of iOS shortcuts for Firefly III (a self-hosted personal finance web app) to let me add transactions on the go. I’ve shared some more details and iCloud links to the shortcuts below.

The first Shortcut is more or less a function that returns a list of accounts. That list is used in the second shortcut to submit the new transaction to Firefly. I wanted to keep the process as quick as possible, so that shortcut requests the least information possible to submit the transaction.

I’ve only just recently switched to using Firefly III; prior to that I had been using Mint for about 8 years. I’ve been increasingly uncomfortable with giving up that much data – and my bank credentials – for a number of years, so I’d been on the lookout for a replacement for quite a while. I’ve probably tried them all, but for one reason or another I couldn’t find an app that fit my requirements.

Firefly is a bit of a change in workflow over Mint, but I’ve found that it’s encouraging me to take a more active role in managing my finances. In part because it doesn’t recommend auto-importing transactions. All-in-all though, it’s working quite well so far.

There are a few places where I’d do things differently in Firefly, but part of the appeal (for me at least) is that it’s built on PHP (Laravel, to be specific) so I could feasibly contribute to it, or at least modify my own fork. It also has a nice REST API and great documentation to go with it, which of course is what these shortcuts are using.

I knew I wanted the ability to add transactions on the go, but logging into the web app is a bit too much friction while waiting in line for a $2 coffee. And let’s face it, if the transaction isn’t added immediately I’ll probably forget about it. So that’s what I’ve solved with these shortcuts.

Shortcut Requirements

  • Your Firefly III instance must be accessible over the internet (I would not do this without using HTTPS)
  • The API supports using a Personal Access Token rather than OAuth, which must be created in Firefly > Options > Profile
  • The Firefly URL and token must be added to both shortcuts

Shortcut can’t find an account?

If no accounts are returned, it’s most likely that the Personal Access Token was denied; either the token was incorrect or, as is common after a Firefly update, the Personal Access Token was essentially deactivated. I often have to delete and recreate it after updates.

Shortcut Downloads

I’ve shared these via iCloud Drive. Load up this post and download the links on an iOS device. Plug your Personal Access Token and the URL to your Firefly III instance into both shortcuts, then test out the Accounts shortcut. It should return a list the asset accounts in Firefly III, along with the current balances.

If you’re not on an iOS device, here’s the what the two shortcuts look like—warning, they’re long:

Screenshot of an iOS shortcut to display a listing of accounts and balances from Firefly III
Accounts shortcut

Screenshot of a Firefly III shortcut that adds a new transactions to a selected account.
New transaction shortcut

Self-Hosting Fathom analytics behind Apache

I’m hosting Fathom on my domain at /fathom. It runs its own web server, so I’ve done this using a reverse proxy that makes the Fathom server accessible at that virtual directory. Their self-hosting instructions do have an example configuration for using Fathom with a reverse proxy through NGINX, but not Apache.

Fortunately the idea’s the same, so adapting it for Apache doesn’t involve too much. It does mean modifying the httpd.conf (or appropriate site-specific config file), and enabling a few additional Apache modules.

The Apache modules needed are mod_proxy, mod_proxy_http and mod_substitute. These can be enabled using a2enmod and restarting Apache:

sudo a2enmod proxy proxy_http substitute && sudo service apache2 restart

Now to enable the reverse proxy, I’ve added a new Location directive the VirtualHost in my site’s config file:

 <Location "/fathom">
        # Host and port of the Fathom instance

        # Updates redirect headers in responses from Fathom

        # Send original Host header to Fathom
        ProxyPreserveHost On

        # Enables replacing of URLs in HTML elements
        ProxyHTMLEnable On

        # Load default mapping of attribute -> HTML elements that need replacing
        Include /etc/apache2/mods-available/proxy_html.conf

        # Define the regex in which to use to replace URLs in HTML
        ProxyHTMLURLMap ^(.*)$ /fathom/$1 [R]

        # Update the location of the /api/ calls in JavaScript responses from Fathom
        AddOutputFilterByType SUBSTITUTE application/javascript
        Substitute "s|/api/|/fathom/api/|niq"

A little more on what each of those directives are doing:

  • ProxyPass
    Creates an entry point at the URL in the Location directive (the first line, in this case it’s /fathom), which in turn forwards those requests on to the Fathom server defined in this ProxyPass directive.
  • ProxyPassReverse
    Replaces redirects sent from Fathom (in the Location header) with the location that the client browser can access. In other words, when Fathom tries to redirect to an internal Login page (, this directive tells Apache to replace that with an externally-accessible URL (/fathom/login).
  • ProxyPreserveHost On
    Fathom’s example NGINX configuration explicitly passes on the Host header from the proxy to the upstream server (Fathom), so it’s safe to assume we should too.
  • ProxyHTMLEnable On
    Include /etc/apache2/mods-available/proxy_html.conf
    ProxyHTMLURLMap ^(.*)$ /fathom/$1 [R]

    These next few directives replace URLs in various HTML elements before sending them back to the browser. For example, <img> and <script> tags will need to be updated to point to the virtual directory (subfolder). Including the proxy_html.conf file imports a default mapping of attributes to elements so that Apache knows which attributes on which elements to update.
  • AddOutputFilterByType SUBSTITUTE application/javascript
    Substitute "s|/api/|/fathom/api/|niq"

    These final directives tell Apache to update URLs in JavaScript files. This is specifically needed for Fathom’s assets/js/scripts.js file, which makes multiple requests to files in the API folder. Just a note that Substitute uses a sed-like syntax for replacing text.

Newly-Rebuilt Web Server

Despite the fact that this site seems abandoned, I’ve maintained it through many iterations and many web servers. For the longest time it was hosted on Dreamhost’s shared hosting, but a couple of years ago I decided it was time to move to my own VPS. I chose a Canadian host, LunaNode.

Initially I built the VPS using Webmin/Virtualmin. The idea was to have the flexibility of my own Linux server with the ease-of-administration of cPanel/WHM. I wanted to focus more on using the server than administering it (ha!) Webmin wasn’t the right solution for that though; I found it to be complicated and inflexible, and I felt that it was constantly working against me rather than helping me. I wanted it to do things The Right Way by default (or easily) but it didn’t. For example, each site should have its own Unix and MySQL accounts, should be able to use different PHP versions, and the FPM pools should run under their respective user accounts. I have no doubt Webmin could do these things, but I decided I’d eventually rebuild it without a control panel so I wasn’t too keen on learning how.

Well I’ve finally taken the time to rebuild the server just as I want it; a panel-less VPS with all the flexibility and none of the overhead. Administering it shouldn’t be much work since I know exactly how everything’s set up. I’ve had no complaints with LunaNode so I’m happily staying there.

Here’s what I’m using:

  • LunaNode s.1 (2 cores, 1GB)
  • Ubuntu 18.04 LTS
  • Apache + HTTP2
  • LetsEncrypt
  • PHP 7.2 FPM (pools running under the user account – finally!)
  • MariaDB 10.3
  • Self-hosted Fathom analytics (Apache acting as a reverse proxy to Fathom’s built-in web server)

I thought about setting up everything through Docker (I’ve been docker-izing everything on my home server) but decided that should be ‘added’ on to a good base server setup instead. It might simplify things in the end, but I felt it would add unneeded complexity while setting up and I’d be better served to sort out the base server first.

I considered NGINX as well; I use it as a reverse proxy on my home server, but for much the same reason as Docker I decided that’s also for another time. I want to use it as a caching server eventually, so when I’m ready to set that up I’ll look into replacing Apache as well. For now, Apache is familiar and easier.