If I want to create my own web hook, do I just need URL to call, say, a REST service or something similar whenever the "trigger" happens?
The part I'm unclear about is how the application itself gets triggered to call the URL (the web hook)? How does the application, let's use Outlook as an example, "know" that ... "hey, an email arrived, I need to send this data to the (web hook) URL"?
So, I create a URL endpoint in a REST service. That part is easy. But, where would you put that URL in, for this example, Outlook to establish the "hook' part in the application?
Thanks very much for replies on helping me understand this concept and how to implement w/o Claris Connect, Zapier, and the like.
As I understand it currently, it would look something like this:
Outlook >---(REST URL) ---> REST API >---FMS data api---> FMS
2 Likes
The place where you define webhooks will be different for each service. For example in Shopify, there is a section in the admin settings UI where you can specify webhook links.
Microsoft is a bit more flexible but convoluted, and I don't have in-depth knowledge. But check out this video starting at ~8:15: https://youtu.be/rC1bunenaq4?t=495
The presenter creates a subscription via HTTP and specifies a webhook url where events should POST event info. He mentions having to renew the subscription every ≤ 3 days, so you may need to run a service that keeps the subscription alive.
I found that video here: Set up notifications for changes in user data - Microsoft Graph | Microsoft Docs
2 Likes
Thanks Josh.
So what exactly does CC bring to the table? We use FMS on AWS so would that work with CC?
I'm still not sure how CC connects to Outlook and since I don't use Outlook myself, I can't test it. The complexity from the video you referenced all seems to be in Outlook itself. That is, getting the right place to add the URL and needing to renew the subscription manually (or with more code to somehow update the subscription automatically). Yuck. Perhaps that's where CC comes in and it manages the Outlook side of things easier?
A REST service is easy to create and the FileMaker Data API certainly seems up to the task.
I'm not a fan of the 'no-code' approach given the large financial costs often levied on non programmers for this convenience, but in this case, there may not be a reasonable alternative.
Thanks in advance,
1 Like
Precisely. CC will store authentication and auto-manage the connection to Outlook. According to the Claris site CC handles these triggers only:
It becomes a value proposition. Calculate how much time CC would save you in learning graph api, writing and maintaining the code. If it you expect fewer than 10k outlook triggers per month, and you think it’ll cost more than $600/yr to write and maintain without it, then CC is the better deal. (They have other pricing tiers than the 600 one too). Also factor in opportunity cost of spending your time learning Microsoft’s API vs doing something else with your time. And if learning Microsoft API is beneficial to your business, then maybe it is worth learning. Even in that case CC can bridge the gap while you learn.
Btw, I should mention that webhook publishing is not guaranteed by the service provider. Therefore they often recommend you write some “reconciliation” code to periodically poll for changes on a schedule. In many cases just the periodic polling is enough. You can run a schedule every 20 minutes on FMS to fetch changes in Outlook, and users might be fine with that vs the real-time webhook thing.
2 Likes
Thanks, but since we don't use FMS Cloud, CC looks more like $3,000 per year for "Standard" if I"m reading that right.
The FileMaker Plus or Essentials tiers won’t work? I think a FMS license subscription for “plus” would be fine, no cloud needed (I could be wrong)
I don’t see “Essentials” in your screenshot.
1 Like
Right, essentials is $99/month, or $1,188 per year. I'm not sure about the other options given that the FMS database is on AWS. Maybe I need to call FMI. Thanks for your great replies and info!
3 Likes
