Hi All,
Looking for some guidance on setting up a webhook for the Microsoft Graph API. For some reason, MS Graph always gives me headaches…
I’m simply trying to graph notifications of any new messages and create an item based on new content from the API.
Here’s the docs:
Set up notifications for changes in resource data - Microsoft Graph | Microsoft Docs
I’ve looked at this setup, but for some reason can’t rap my head around this one…
Any help is appreciated!
Edit: I have an API Workflow retrieving the validationToken, and I have successfully subscribed (created) a webhook via the API connector.
However, there isn’t currently a way to have two API Workflows with the same name, which in this case I would need both to detect data and a manual definition as the validationToken is a querystring but the data needs to come through as a detect data…
@Jici - tagging you as you’re an API wizard… lol. Any advice? 
I think that the main issue you will have actually is to get the validationtoken that is set in a query string that Bubble will not detect (even if you choose manually) in POST request. While it’s not a problem when you use GET request. Without this limitation, the solutions is easy. This will depend if Bubble will handle both body and querystring (they should) or not.
If yes, you can use Postman to initialize the API. If not, you will first set the validationToken in parameters and return it to MS Graph and after you will use Postman to initialize the endpoint with the real payload.
So actually, the only way I can see is to use another tool like make/integromat. but you should send a support ticket to Bubble because having querystring parameters with a body JSON is something that happen often and Bubble should handle this.
Thank you @Jici - I’ll reach out to Bubble and see what can be done.
hi @lantzgould - just wondering whether or not you ended up getting this working?
Trying to do the same thing myself and knowing whether or not there’s a working solution might save a lot of headaches.
Thanks!
Hey @Jici - Nice to meet you! I hear you’re the one to ask about Bubble APIs.
I’m still having issues with this and was wondering if you’ve heard of a workaround? Bubble doesn’t let you have 2 workflows (1 for the manual validationToken response and 1 to automatically detect the subscription payloads), and having to initialize the API workflow with “\initialize” causes issues because I can’t change the Graph API notifications URL which has been used to create the subscription.
In summary, I have:
I managed to get a workaround functioning in Make (see below), but I’d really rather get this working in Bubble if possible.
Thanks!
Hi all,
Has anyone had any success making this work (esp. @Jici)? Have reached out to Bubble’s customer support and their response was awful, basically, “we’re not going to support querystring and JSON body”.
I really don’t want to go through Make but it seems like that is the only other option?
Thanks
Hey @joshphillips
Couldn’t get this functioning in Bubble, but got it working by building an Azure Function app which handled both the validationToken and updates and then passed the subscription updates onto my Bubble app. There are quite a few resources on the web for this, and was much more economical than dealing with Make.
After I got it working, I realised that it was overkill for what I needed. Ad-hoc and periodic subscription updates served my purpose, so just built this capability through standard graph API calls in the app backend.
Hope this helps.
Thanks @matthew18 ,
The Azure Function approach might work. I’ve also been contemplating whether I just do a periodic update for calendar events, i.e. overnight for each user. Since my platform is relatively small it should be OK computationally.
Thanks!
glad it helped @joshphillips. Periodic and on-demand updates met our needs fine. For anyone else looking into this, if instantaneous updates aren’t an essential requirement for your app, I’d highly recommend this approach not only for simplicity and reliability reasons but also as a way to dramatically reduce WUs.
Happy building!
I more recently shifted to using data calls (rather than actions) so that I don’t have to keep the data up to date using webhooks. It’s been way more computationally efficient and more reliable. It requires some javascript in some cases but it’s pretty standard and if there are any issues ChatGPT/Claude/etc. can help navigate the issues.
Great call @joshphillips. The Toolbox javascript plugin is so powerful. We also make a lot of use of server script in the backend workflows, particularly when it comes to organising data and getting it ready for being pushed to Bubble. And 100% agree about ChatGPT. Can get you 90% of the way and is a massive time saver.
