SDK and CLI Debug Logging

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.

Sensitive Information in Debug Logs

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.

Collection and Sharing

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.