Skip to main content

CloudEvents

CloudEvents is a specification for describing event data in a common way. While implementing our Webhooks service, we decided to adopt the specification as much as possible to make it easier to you to adopt and manage our notifications.

You don't need to know the content of these documents to use our Webhooks, but it could be useful in case you want to use them in combination with other CloudEvents-compliant systems. For example, you could find the CloudEvents SDKs useful for your purposes.

Please, check the Notifications and Specifications page to check the actual Fatture in Cloud's Webhooks implementation.

☁️  The Specification​

At the time of writing, the latest release of the specification is v1.0.2.

Our Webhooks implementation is based on a few documents of the CloudEvents Specification, in the next section we described which ones were used and with which grade of compliance.

❤️  Core Specification​

Our Notifications are compliant with the CloudEvents Core Specification.

🌐  HTTP Protocol Binding​

Our Notifications are compliant with the HTTP Protocol Binding for CloudEvents document; in particular, we adopted the Binary Content Mode, including the CloudEvents Attributes as HTTP Headers to the REST request. Even though we choose the Binary Content Mode as our default, you can still choose to use the Structured Content Mode if needed by requiring it in the subscription request.

🧲  Webhooks​

Our Notifications and Subscription process are partially compliant to the HTTP 1.1 Web Hooks for Event Delivery document. For example, we decided to not implement section 4 of the document, but we decided to adopt the Abuse Protection solution used by other Webhooks providers in the Verification step. Check the Subscriptions page for further info.

📝  Subscriptions​

Our Subscriptions process is loosely compliant with the CloudEvents Subscriptions API document. At the time of writing it is still a work in progress, so we followed the main guidelines of this document but we decided to not implement every section of it.

For example, we don't support the source, config, filters, sinkCredentials, and protocolsettings parameters in the subscription request; also, since we support only the HTTP protocol, we don't require to set the protocol parameter, and it would be ignored by the request.

When the first release of this document will be available we'll review it and decide if it makes sense to adopt it entirely for our system.