Additional information requested for fetch available appointments webhook event #10
-
Hello, Just wondering, if we implemented the synchronous fetch available appointments, and didn't implement asynchronous fetch available appointments, do we need to implement the fetch available appointments webhook? If we should still implement this webhook event, why someone would choose to receive the response through the webhook rather than just getting the results synchronously? Thank you! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Great question! Synchronous APIs are the preferred option, as they eliminate the need for an asynchronous option in most cases. However, there are cases where an asynchronous option may be helpful. One example is a user who wants to load multiple appointment schedule times in batch for easy consumption for their internal users. To make their process as easy as possible, they could subscribe to the fetch-appointments webhook and provide a single endpoint to consume the data. Once that service exists, they can create a batch process to trigger calls to various companies on a schedule. This could eliminate a lot of specific custom logic for this specific user supposing everyone implements webhooks. Providing the functionality would provide the most flexibility for users, but ultimately it will still be rare requirement. |
Beta Was this translation helpful? Give feedback.
Great question! Synchronous APIs are the preferred option, as they eliminate the need for an asynchronous option in most cases. However, there are cases where an asynchronous option may be helpful. One example is a user who wants to load multiple appointment schedule times in batch for easy consumption for their internal users. To make their process as easy as possible, they could subscribe to the fetch-appointments webhook and provide a single endpoint to consume the data. Once that service exists, they can create a batch process to trigger calls to various companies on a schedule. This could eliminate a lot of specific custom logic for this specific user supposing everyone implements we…