Skip to main content

Webhooks

In this section we describe the webhooks functionality offered by the Fatture in Cloud APIs.

The webhooks are a pattern to deliver notifications between applications via HTTP endpoints, allowing external applications to register an HTTP endpoint to which notifications are delivered.

This is not Generally Available!

The Webhooks are still in a Closed Beta version, so they are not Generally Available yet. It means that if you try to subscribe without prior approval, you'll receive an error.

Please check the Subscription guide to know how to apply for the Beta Testing group.

What about Zapier triggers?

Zapier Triggers are based on the Webhooks functionality, but they're already available to all our users. Feel free to use them as much as you want!

❓ Use case​

Without a webhooks functionality, REST APIs are usually passive: the actions are triggered by applications through the exposed API methods, but the application would not be able to detect a change on one of the resources automatically; in most of the case, it means that the application will be forced to perform a list of all the resouces with a Polling strategy, consuming API quotas and computation capabilities for requests that could also be futile in the case nothing happened since the last check.

Thanks to the Webhooks, all the applications that are able to expose an endpoint can be notified when something happens on a resource, greatly improving the syncronization of the state with the Fatture in Cloud data.

🚀  Let's go!!!​

Below you can find all the available pages about the Webhooks functionality:

🤷‍♂️ I can't do it!​

If your system is technically unable to implement a Webhooks Target, we still suggest to syncronize your application properly:

  • Don't use a high frequency for your syncronization attempts: you should calculate the number of requests needed by your application to perform a complete scan of the resources and choose how often to syncronise all the resources, in order to avoid exceeding the API Quotas
  • Implement your Polling Strategy wisely, by introducing a delay between each request and introducing an exponential backoff functionality in case of errors
  • If possible, reduce the number of requests by keeping track of the already processed resources and stopping the list loop when all the new resources are retrieved
  • Customize the List Method Response by using the fields and fieldset parameters, in order to avoid to perform Get calls to retrieve the detailed status of the resource