This is the fifth development log for my project Exist Integrations.

See previous entries: 4, 3, 2, 1.

Migrating the code base for Exist Integrations into the new framework has been way more work than I originally imagined. When the Exist API v2 was announced, I was excited and ready for the challenge. As life happened and the days turned to weeks and then months, it became a source of some stress. I always knew I would finish it but I figured I had a lot of time. Today, as I was wrapping up the work on the fourth integration to be ported over I re-read Josh’s announcement of API 2 one element stuck out to me:

API 1 access will be removed on 1 February 2023

Shit! Today is 22 January. That means that in 10 days the great folks at Exist want to deprecate v1. Exist Integrations was only using v1 of the API.

That was all the motivation I needed. Today, I wrapped up the Toggl Track integration and now my user is entirely using the new Exist Integrations v2 framework.

I know there are bugs and some oddities. I’ve included those in the roadmap with workarounds. However, there could be more. So, the big question is how do we move forward? Here is the timeline of events that will happen:

• All active integrations on Exist Integrations v1 will be turned off on 31 January
• All active users will be ported over to the Exist Integrations v2 server on 31 January
• Users will be unlocked on Exist Integrations v2 on 1 February
• Email announcing the details will be sent to the active users today, 22 January

In the email, I will offer to the users if they are able to help test the new code base, I can port their users over early. I’ll be allocating time each day to investigate bugs and help users out so that the launch is less shaky.

With that said, let’s talk about the Toggl Track Integration!

21 - Toggl Track Integration

I started work on this yesterday. I was very happy that porting over the logic from v1 to v2 went so quickly. So many patterns had been set and I was familiar with the data and return from Toggl Track.

The Toggl Track integration did pose a few challenges. The overall logic is very similar. Once you connect to Toggl Track, you’ll figure which time tracking Projects correspond to different time-based attributes from Exist:

• Productive time
• Neutral time
• Distracting time
• Time gaming
• Time watching TV
• Time watching Movies

I dropped support for Pomodoros since it wasn’t used. Since the Trakt integration created a new attribute on Exist, it was simple to allow the same attribute to be used for Toggl Track. The only challenge is that if either the Time watching TV or Time watching Movies was used in the Trakt integration for the user, the site couldn’t present it as an option for Toggl Track. Attributes can only be sourced from one service. Thankfully, I came up with a good solution that could be extended to other sources if/when I choose to allocate time towards them.

The processor work went really quick. I was happy with a lot of the logic from the v1 processor. I chose to use the delta logic that I created in the YNAB processor. Unfortunately, I found a limitation of the Exist v2 API that could impact time entries if they are modified in Toggl Track after they have been sent to Exist. If the date changes or the total time decreases, those messages are not able to be sent to Exist right now. If the total time of a time entry increases, that will work properly. There is only so much I can do with the time I have, so I was forced to create a To Do. I was confident in that choice because there is a way for a user to correct the data with the Zero Out functionality to reset the values in Exist for the attributes from the service. It’s not ideal, but it’s functional.