Webhooks - How would you use them with FreeAgent?

Feature Requests
#1

Hey :wave:t3:

I’m Stu, the Core Services:API Product Manager at FreeAgent. If you’ve posted on the forum recently then we’ve probably spoken, but if not then nice to meet you :grinning:

I’m very keen to hear from developers who would like to see FreeAgent support webhooks, and more specifically, context around how you might envision using them, why they would benefit you, for what areas of an account would you use them for etc.

We’re doing some exploratory research in this area so please feel free to post your thoughts and opinions here, and as always the more context the better. Consider this thread a single feature request that everyone is welcome to contribute to. :family_man_woman_girl_boy:

Cheers

Stu McEwan
Core Services:API Product Manager

Are webooks on the API feature roadmap?
#2
#3

Webhooks would significantly reduce the read load I put on the API. Currently I read lots of data from many of the API’s collection endpoints every 30 minutes (reducing to every 10 minutes soon). If webhooks existed I would only need to bulk-read each resource once, and from then on I could just listen to the webhooks for changes.

While it’s always nice to do existing things more efficiently, I’m much more excited at the prospect of webhooks for deletions. The API doesn’t provide a way to find out what’s been deleted in FreeAgent (as has been noted here before :slight_smile: ) and there isn’t a neat way to derive it either. My system not knowing that a resource has been deleted in FreeAgent generates a steady stream of support requests for me from my users. Deletion webhooks would be a whole new capability rather than a variation on existing capabilities.

After deletion webhooks, the most useful one for me would be hearing when new bank transactions have been created. Most of the things my system does revolve around explaining bank transactions and it would be nice to be able to do that as soon as transactions appear in FreeAgent, rather than at the next scheduled sync.

Thanks!

#4

We are currently looking at building extra reporting dashboards tailored to our business as well as notifications if our staff havent completed time sheets, projects are going over budget, and link up tasks in our project management / planning platform to timesheet entries in freeagent as welll as some other bits.

If we were to do this without webhooks it would be very API heavy as we would have to poll very regularly to ensure everything is up to date. There would be no way to know if, for example an invoice or bank transaction had been updated which would skew our reporting. If we wanted to report on the last year of billing we would have to get the data from scratch every time as keeping cached data in sync would be tricky. If using webhooks however we could cache all the data and just update the changed records when the webhooks are triggered.

Asana has a good implementation of webhooks that we use: https://developers.asana.com/docs/webhooks

Thanks! Jonny

#5

I’d love to be able to use webhooks to keep our reporting database in sync. It would drastically reduce the amount of times we need to hit the API as we only need to listen for Create, Update or Delete and also don’t need to sync when there’s no activity. Also, at the moment we don’t have an endpoint for deleted items so the only way to purge them from our database is to hit all pages of the endpoint and basically do a full reload.

1 Like
#6

Thanks for the posts so far, it’s very much appreciated.

As always, we’re very keen to learn more about how the current workflows of integrations that connect to FreeAgent could be improved.

From everyone at FreeAgent, we wish you all a happy holiday season.

Stu McEwan

API Product Manager

#7

Fully supporting what you are saying!

#9

As mentioned here, this will be helpful to track deleted items. Although there are still part of Journals that needs to be fixed. If you’re updating a journal, you’ll notice that the updated_at doesn’t get updated and that’s a hole because we’re only relying to the updated_since parameter when syncing record to reduce the load.