Targets
A Target is a delivery destination within Event Channels. Targets define where matching events are sent. A single target can be attached to multiple subscriptions, so you can reuse one Slack channel or webhook endpoint across different event routing rules.
On sites without Workspaces, all targets are site-level. On sites with Workspaces, targets are scoped to the workspace where they are created. Workspace Administrators create targets within their workspace for use in their own subscriptions.
Site Administrators in the Default Workspace can enable Apply to All Workspaces on a target, which allows it to receive events from every workspace on the site. To deliver events from other Workspaces through a subscription and target in the Default Workspace, both must have Apply to All Workspaces enabled.
A target's scope controls which events the destination accepts; it does not expand the events matched by its subscriptions. For email targets, recipients must still be users in the Default Workspace even when the target is set to apply to all workspaces.
Target Types
Files.com supports the following target types with Event Channels. Each target can be reused across multiple subscriptions.
Email targets deliver batched event summaries to one or more users on your site. Multiple Recipient Users can be selected on a single target. The batch interval is configurable between 10 minutes and 24 hours. Recipients do not need to be Site Administrators.
Each subscription's Email Content settings control the subject and message of the emails it generates.
Webhook
Webhook targets deliver a JSON event payload in an HTTP POST to an HTTP or HTTPS URL for each matching event. Custom request headers are supported.
When your site has dedicated IP addresses, enabling Use Dedicated IPs on the target sends deliveries from the site's default dedicated addresses, which you can allowlist in the receiving system's firewall. It does not select an additional Custom Domain's addresses. With the option disabled, deliveries use the Files.com general IP pool.
Webhook URL Requirements
Webhook, Slack Webhook, and Teams Webhook targets send requests from Files.com's servers, so their URLs must be reachable from outside your computer or private network. Each destination must resolve to an allowed public IP address and use port 80, 443, or a port above 1024, under the same destination rules as Notifications webhooks. Slack Webhook and Teams Webhook targets require HTTPS.
Saving a target checks the URL's format and scheme. It does not resolve the hostname or check the destination address or port, so a target can be saved even when its URL does not meet the delivery requirements.
Files.com checks the destination every time it delivers an event. It does not send to private, loopback, or link-local addresses, to a disallowed port, or to a hostname that cannot resolve. The Delivery Attempt records Webhook URL is invalid when a destination fails these checks. These rules apply in every Workspace and through the web interface, API, CLI, and SDKs.
Webhook Signatures
Configure a signing secret on the target so your receiver can verify each message before acting on the event. The API setting is config.signing_secret. A nonblank secret enables signing; without one, Files.com does not generate a signature. Keep the same secret privately in your receiver's configuration. This secret belongs to the target, so it applies to deliveries from all subscriptions that use that target.
Use X-Files-Signature-V2 for new and existing integrations. Its value is the HMAC-SHA256 digest of the exact received JSON body bytes, using the signing secret as the key. The header contains 64 lowercase hexadecimal characters with no sha256= prefix. Verify those bytes before parsing JSON; do not calculate the digest from a reserialized object.
Require a valid V2 signature and compare it using a constant-time comparison function. Reject a request with a missing or invalid V2 signature without falling back to an older header.
The receiver verification example applies to Event Channel webhooks using its POST branch and the target's signing secret. A valid signature does not establish that the event is new or unprocessed; handle repeated deliveries separately from signature verification.
The older X-Files-Signature header is deprecated and remains available for compatibility.
Slack Webhook
Slack Webhook targets default to a human-readable message for each matching event. The message content is generated from the event title, summary, and key fields. You can optionally use Subfolder Summaries for file activity. The URL must use HTTPS and meet the webhook URL requirements.
Teams Webhook
Teams Webhook targets default to a human-readable message for each matching event using the same generated content as Slack. They support the same optional Subfolder Summaries for file activity. The URL must use HTTPS and meet the webhook URL requirements.
Amazon SNS
Amazon SNS targets publish event payloads to an SNS topic. The target requires a Topic ARN, Access Key ID, Secret Access Key, and Region. Credentials (Access Key ID and Secret Access Key) are not shown after saving and must be re-entered to replace them.
Google Cloud Pub/Sub
Google Cloud Pub/Sub targets publish event payloads to a Pub/Sub topic. The target requires a project ID, topic ID, and Google credentials. For security, the private key inside the credentials is not retrievable after saving. Record it before saving the target.
Folder
Folder targets stream matched events to a destination folder instead of pushing them to an endpoint or service. Use this when the consuming system reads files on its own schedule rather than receiving pushes, or when you want only specific, filtered events instead of everything Log File Streaming would write.
The destination folder can be a folder on Files.com or a folder on a Remote Server Mount. Folder targets write files in JSON or CSV format on a batch interval configurable between 10 minutes and 24 hours. You choose the format when you create the target, and cannot change it afterward. The destination folder and batch interval remain editable.
A folder target on a Partner Channel Route Path writes into that route's target folder. The destination's file rules still apply. Event content retains the producing Site's recorded paths, regardless of where the target delivers the batch.
Files.com writes each file once, as a complete output, at the end of its batch interval, and does not modify it afterward. A file is safe to process as soon as it appears, with no risk of partial or still-changing data. The next interval's events go to a new file.
Files.com names each file events-[delivery attempt ID]-[timestamp].[extension], so you can trace any delivered file back to its own Delivery Attempt record. The timestamp reflects when the file was written, so a system polling the destination folder can order files chronologically and process them in the sequence they arrived.
Notifications also support email, webhooks, Slack, Teams, SNS, and Pub/Sub for file and folder activity alerts. Event Channel targets and Notifications are configured and managed separately.
Subfolder Summaries
Slack and Teams targets can combine matching file activity events into a shorter message when a team needs counts for a busy upload folder. Set the target's Message delivery to Subfolder summary and choose the folder whose activity should be summarized. Immediate delivery remains the default.
Summaries group operation counts by the chosen folder's first-level subfolders, including deeper files. Files directly in the chosen folder are counted under that folder.
Counts describe operations rather than distinct files, exclude folder operations, and do not list filenames. Send after inactivity accepts 15–300 seconds and defaults to 60 seconds; continuous matching activity is summarized after a maximum of 10 minutes of collection. The folder notification guidance explains how to choose the inactivity period and why a summary does not confirm that an Inbox submission is complete.
The delivery mode, summary folder, and inactivity period belong to the target and apply to every subscription using it. Each subscription's matching activity is summarized separately, with separate summaries for each Workspace.
Subscription event types and filters continue to determine what contributes, and subscription and target Workspace scopes must both allow delivery. Other matching event types and file activity outside the chosen summary folder deliver immediately. Different targets on one subscription can choose different delivery modes.
Changing the relevant delivery configuration discards pending summaries. Events that contribute to the same message share its delivery result and retry schedule.
Delivery Batching
Email and Folder targets batch events together on a configurable schedule between 10 minutes and 24 hours. Email targets deliver a summary to their recipients at the end of each interval.
Folder targets write that interval's events to a file in the destination folder. Email target batching is separate from admin email alert batching, which Files.com spaces out automatically, starting at 3 hours and widening the gap to a maximum of 24 hours.
Webhook, SNS, and Pub/Sub targets deliver one payload per event as events occur. Slack and Teams do the same by default; their optional subfolder summaries use an inactivity period rather than the periodic Send every interval used by Email and Folder targets.