Stored Credentials
Files.com stores credentials so connections and workflows can authenticate to other systems without asking someone to enter a secret for every operation. Reviewing that access involves both the saved configuration and the records produced when it runs. A secret withheld from a configuration read can still appear in a request you supply, a custom webhook header, or a client's debug log.
Permission to use a connection is separate from permission to retrieve its credential. A user can work with a Remote Server Mount through the configured remote account without receiving that account's password. The remote account's permissions still determine what the connection can do.
Saved Secrets
Write-only secrets are accepted when you configure a feature and retained for its operation, but are not returned when you read, list, or export the configuration. Replacing one requires entering the replacement value; reading the saved configuration cannot recover it.
For Google Cloud Pub/Sub Event Channel targets, the private key inside the Google credentials is write-only. This applies regardless of how the credentials were supplied.
SMTP and LDAP passwords saved in a Child Site Management Policy are encrypted and write-only, including for the Parent Site. Child Site Administrators can see which settings the Parent Site manages, without receiving the policy's saved values. This supports visibility into centrally managed settings while keeping their credentials private.
Write-only storage does not remove a secret from copies made before or during submission. Keep the source credential in your organization's credential storage. API keys have a different issuance process: their secret is shown once at creation, and a lost value requires a new key.
Request and Webhook Logs
API request logs record activity without retaining recognized credential values in the logged request path. For example, a Share Link registration code supplied with a file request is filtered out of the recorded path. This filtering applies before the path is recorded, rather than hiding it only from particular viewers.
Webhook Logs serve a different purpose: they record the HTTP request headers Files.com actually sent, including custom header values. A credential placed in a custom header therefore appears in that log. Files.com cannot infer which arbitrary custom header values are secrets.
Site Administrators can view and export Webhook Logs across the site. Workspace Administrators can do so within their own Workspace. Folder Admin permission does not grant access to those logs, including for a subfolder beneath the webhook's configured folder. Choose custom headers and log access together, and treat an exported log as another copy of any credentials it contains. Client debug logs have their own collection and handling requirements.
URLs and Their Authority
A signed upload or download URL is a bearer credential: anyone presenting the complete URL can perform its authorized transfer until it expires, subject to applicable connection restrictions. This applies to Native Storage as well as Files.com Agent transfers. The URL grants that transfer rather than general site access. Its expiration is separate from the requesting user's session, so ending the session does not immediately invalidate an already issued URL.
An email-preferences link instead authorizes changes to mail subscriptions. It does not sign anyone in, provide file access, or return Share Link access codes. For a user's Share Link notifications, it offers one opt-out covering all current active subscriptions; changing an individual link's notifications requires signing in.
The user's preferences token goes only to the primary mailbox. Copies sent to Additional Email Recipients carry separate tokens for those recipients' own preferences. Keep preferences links private because they permit subscription changes, while distinguishing that authority from the account credentials and sessions governed by Access Revocation.