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.

Webhooks Now Generally Available

The Webhooks feature is no longer in Closed Beta and is now available for all users without prior authorization. You can freely create subscriptions and start integrating webhooks into your applications.

While we've worked to ensure stability and coverage, if you encounter any issues or notice missing events, we still encourage you to report them so we can continue improving the service.

 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