Webhooks & Event Delivery

For Notifications, Webhooks deliver information to configured HTTP endpoints. Review the selected events and payload: a webhook can send file details, and a configured payload can include file contents. Every primary and backup URL receives its configured requests; a backup URL is also a destination that must be approved to receive the data.

Notification Destinations

The same destination rules apply to Slack and Microsoft Teams notifications. Files.com validates every destination before saving a new notification or changes to its webhook settings. URLs must be well formed, use HTTP or HTTPS on an allowed port, and resolve to allowed public addresses. Destinations that resolve to private, loopback, or link-local addresses, or whose hostname cannot resolve, cannot be saved. The rules apply in every Workspace and through the web interface, API, CLI, and SDKs.

The Slack and Teams notification types determine the message format; they do not restrict the destination to the provider's domains. Approve the destination to receive the included file details, even when it passes URL validation.

This validation does not send a test HTTP request or require a successful receiver response. A Webhook delivery test checks a different question: whether the receiver accepts the request. Overriding a failed delivery test does not bypass destination validation. If validation cannot finish, the save fails and the previous configuration remains intact.

Event Channel Destinations

Event Channel targets use the same public-address and port requirements for Webhook, Slack Webhook, and Teams Webhook deliveries. Saving a target checks the URL's format and scheme without resolving its hostname or checking its destination address or port. Webhook targets accept HTTP or HTTPS; Slack and Teams targets require HTTPS. A saved target can therefore have a destination that Files.com will not deliver to. These rules apply in every Workspace and through the web interface, API, CLI, and SDKs.

Delivery-Time Checks

For both Notifications and Event Channel targets, Files.com checks the destination every time it sends. It does not send to private, loopback, or link-local addresses, disallowed ports, or hostnames that cannot resolve. An Event Channel Delivery Attempt records Webhook URL is invalid when the destination fails these checks. A saved URL is not a promise of future delivery: DNS, receiver availability, credentials, and receiver behavior can change. Use HTTPS for confidential deliveries, maintain any receiver credentials, and monitor the delivery results for the workflow you depend on.

Receiver Verification

Configure a shared secret so the receiving system can verify a delivery before acting on it. Folder webhooks use their Verification token; Event Channel webhook targets use their signing secret. With a nonblank secret configured, X-Files-Signature-V2 carries an HMAC-SHA256 signature of the complete POST body, or the complete query string without the leading ? for a GET folder webhook. The receiver verifies the exact received bytes with the same secret.

Require a valid V2 signature on every delivery and reject a missing or invalid one. The older folder webhook signatures use MD5, and the folder webhook's X-Files-Signature checks only the file path. The Webhook Signatures reference and Event Channel signature guidance explain receiver verification and handling repeated deliveries separately.

The shared secret is the key behind the signature: anyone holding it can generate a matching signature. Keep a separate secret for each receiving integration. Files.com-generated folder webhook tokens use cryptographically secure random values, independent of other generated tokens; knowing one does not reveal another. Replacing a token requires updating the receiver's copy too.