Client Software
The official Files.com SDKs, CLI, and connectors run in your environment using the credentials you configure. They connect your applications and local storage to files that other users or systems may supply. Server verification, local destination selection, and logging each protect a different part of that exchange.
Files.com permissions determine what the connecting account can request. Your operating system and applications control the files, credentials, and diagnostic copies retained after delivery. Choose an integration credential for the work the client needs, and include the machine running it when reviewing who can read those copies.
Server Verification
Official Files.com client software verifies the server's TLS certificate before sending an API key over HTTPS. The certificate must chain to a trusted authority and cover the requested hostname. Encryption and server identity work together: an encrypted connection alone does not establish that a credential is going to the intended server.
Keep certificate verification enabled in the application's HTTP configuration. Transfer Encryption & Algorithms explains this distinction, and TLS connection troubleshooting covers connection failures.
Local Download Paths
Anyone who can upload to a folder can choose names for the files its readers download. A remote filename is therefore supplied input, rather than authority to select an arbitrary location on the reader's computer. Files.com and the local operating system can also have different naming rules: on Windows, for example, a colon has a path-related meaning rather than being an ordinary filename character.
When a download does not specify a local path, the client saves the file in the current working directory under the remote file's name. It rejects a name that the operating system would interpret as another path or a reserved device instead of using it to write elsewhere. The Desktop App likewise keeps downloads within the selected local destination when deriving paths from remote names.
An explicitly supplied local path is your application's destination choice. Select that path deliberately when a remote name is unsuitable for the local system. The CLI download reference explains destination handling and overwrite behavior. Files.com's folder permissions govern the source; they do not become local file permissions after download.
Logging
Normal, non-debug logging omits raw transport detail and does not record signed transfer URLs. A signed URL authorizes a transfer, so recording it would give a log reader that transfer's temporary access.
Debug logging in the Files.com SDKs and CLI records detailed transport information to help diagnose connection and API problems. It captures request and response headers, payloads, and URLs broadly and without redaction. This detail is intentional: troubleshooting can depend on the exact information exchanged by the client and service.
Debug logs can contain API keys, remote server credentials, GPG keys, file contents, personal information, and other material present in requests or responses. Secrets in those payloads can appear in plain text. Treat a debug log as a copy of the information exchanged, with access and handling requirements appropriate to that information.
An encrypted HTTPS connection protects data in transit. It does not conceal data from the client making the request, and it does not encrypt or redact the client's diagnostic output. Similarly, Files.com permissions limit what the client may receive; they do not protect a log after the client has saved it elsewhere.
Enable debug logging only in a controlled environment where recording that information is acceptable, and disable it when troubleshooting is complete. Limit access to the resulting files and to any logging service that receives them. Logging configuration determines where those copies are stored and who can read them.
Before sharing a log, review its contents and remove sensitive values the recipient does not need. Do not assume that a debug log is safe to attach to a public discussion or share widely because it was generated by an official SDK. If a credential has been disclosed to someone who should not have it, replace or revoke that credential; deleting one log copy does not invalidate it.
SDK Logging covers SDK log levels. CLI debug logs describe the CLI option and an example command. These client diagnostics are separate from the platform activity records described in Logs and Reports.