Calendar Plugin - Webhooks and Background Updates?

[pet]

Hi,

I am interested in this Bubble Calendar Plugin:

Calendar From Google + Offline Plugin for Bubble, by Zeroqode

If I understand it right, the user registers in my Bubble App using their Google account. Then, they give permissions to my Bubble App to e.g. create appointments in their calendar.

BUT: is this only valid for the actual user using my app? Or is it possible, that I create background workflows that are triggered by events in my app and then create events in the users calendar?

Second: does this plugin enable push notifications / webhook from Google Calendar to my app? So that if the user deletes an event using the native Google Calendar Webinterface, my app will be informed instantly?

Thanks for your indepth info.

Best regards,
Peter

[levon]

Hello, Peter,

If I understand it right, the user registers in my Bubble App using their Google account. Then, they give permissions to my Bubble App to e.g. create appointments in their calendar.

this is correct

BUT: is this only valid for the actual user using my app? Or is it possible, that I create background workflows that are triggered by events in my app and then create events in the users calendar?

although should be possible it might be very tricky to get this implemented. Depends on a use case.

Second: does this plugin enable push notifications / webhook from Google Calendar to my app? So that if the user deletes an event using the native Google Calendar Webinterface, my app will be informed instantly?

webhooks are not implemented out of the books but here is how to set them up
but we can try to implement them as described here https://developers.google.com/calendar/v3/push
and then in your Bubble app you will be able to manually create an API endpoint (API workflows tab) which will be the URL for receiving the webhooks from Calendar.
Hope this helps

[pet]

Hi Levon, thanks for your quick answer!

although should be possible it might be very tricky to get this implemented. Depends on a use case.

So my usecase is a schedule booking app.
Step1: The service provider registers in my app and gives permission for his Google Calendar to the app.
Step2: A client runs my app, finds a free booking slot and books the service at the specific time slot.
Step3: The app creates an appointment in the service providers Google Calendar and notifies via email.

So in fact, although the service provider registered in my app (which is my actual user) and gave permission for the calendar, the appointments/bookings themselves should be generated regardless of the service provider beeing logged in my app.

Hope this describes my usecase in a useful way.
Regards

[levon]

Hey Pet
thanks for the details.
I believe it should be possible but might be tricky and might require some custom code (but not necessarily) - it might be much easier if you have first notified the service provider and then the service provider logs in and clicks “confirm” and only then the event is added to the google calendar.
Hope this makes sense
Thanks

[pet]

Hi levon,

I believe it should be possible but might be tricky and might require some custom code (but not necessarily) - it might be much easier if you have first notified the service provider and then the service provider logs in and clicks “confirm” and only then the event is added to the google calendar.

This is not possible for my workflow.
But if I understand the Google Calendar API right, the “access_type=offline” tag in combination with the refresh token should allow the app to get unlimited access, so no OAuth screen with user interaction should be needed.
I assume that the plugin checks for the auth token and refreshes it with the refresh token if needed. After that, the API calls can be made. If I run this in triggered workflows, the plugin should work without the Provider beeing logged in?? Or am I missing something?

[levon]

your assumption is right, but only when the user is logged in and is trying to access his/her account. If it’s a backend operation the trickiest part that I meant is running the operation under a certain user as if being logged in as them. You see what I mean?