Files.com is the cloud-native, next-gen MFT, SFTP, and secure file-sharing platform that replaces brittle legacy servers with one always-on, secure fabric. Automate mission-critical file flows—across any cloud, protocol, or partner—while supporting human collaboration and eliminating manual work.
With universal SFTP, AS2, HTTPS, and 50+ native connectors backed by military-grade encryption, Files.com unifies governance, visibility, and compliance in a single pane of glass.
The content included here should be enough to get started, but please visit our Developer Documentation Website for the complete documentation.
The macOS binaries require macOS 13 or later. Building from source requires Go 1.27.1 or later.
The Files.com Command Line Interface (CLI) App is a great option for scripted or automated transfers between a local machine and Files.com.
Because it works through the standard Command Line, the CLI app is easy to script from a variety of environments without having to use our SDKs. With that said, if you are already using a programming language where we offer an SDK, the SDK may offer a higher level of integration for your application.
The CLI App is cross-platform (Windows/macOS/Linux) and supports fast, concurrent file transfers.
The CLI App uses the Files.com RESTful APIs via the HTTPS protocol (port 443) to securely communicate and transfer files so, when used interactively or from a script, no firewall changes should be required in order to allow connectivity.
The CLI supports all file Operations including list, download, upload, move, rename, delete, etc. But equally important is that it supports operations on every resource available in Files.com including Users, Permissions, Groups, Remote Servers, Behaviors, etc.
The available resources are listed in this documentation under the Resources menu on the left.
When files-cli download or files-cli sync pull processes at least 500 eligible small files, it can batch them through the ZIP download path instead of issuing one download request per file. Files are eligible when they are smaller than 128 KiB.
The ZIP is only the transfer format. The CLI extracts each entry as it arrives, verifies it, and writes ordinary files to the requested local destination. It does not save a .zip archive.
ZIP batching is enabled by default and adjusts per job. The CLI starts with 16-file ZIP batches, can grow batches up to 32 files per stream, and compares ZIP throughput against normal per-file downloads. It keeps the ZIP path only when that path measures faster, and long jobs can re-check the decision as network conditions change.
Use --no-zip-batch to disable ZIP batching for a download or sync pull. Use --force-zip-batch for targeted performance testing when you want to bypass the automatic speed check.
Download the latest release for Windows, macOS, or Linux from the CLI App Releases page.
On that page, you'll need to pick your exact operating system to download the correct version.
On 64-bit AMD/Intel Windows systems, the MSI installer places the CLI in C:\Program Files\Files.com-CLI and adds that directory to the system %PATH%. Portable archives are also available and can be stored anywhere on your computer.
When using a portable archive, we recommend placing the app binary into one of the folders listed in your %PATH% (Windows) or $PATH (Linux and Mac).
Here are specific instructions, grouped by OS:
Download
- AMD/Intel 64-Bit Processors MSI installer (Recommended)
- AMD/Intel 64-Bit Processors portable ZIP
- ARM Processors portable ZIP (Less Common)
Run the MSI installer (*.msi) to install files-cli.exe and add it to the system %PATH%. Open a new terminal before running files-cli.
For a portable installation, download the Zip archive (*.zip), extract it, and place files-cli.exe into any directory listed in your %PATH% environment variable.
For systems with Homebrew 6.0 or later, trust the Files.com CLI formula before installing it:
brew tap files-com/tap
brew trust --formula files-com/tap/files-cli
brew install files-cliThe brew trust --formula files-com/tap/files-cli command trusts only the files-cli formula. To trust the entire Files.com tap instead, run brew trust files-com/tap before installing. Homebrew versions earlier than 6.0 can install without the brew trust command.
Download the compressed Tar archive (*.tar.gz), extract the files from the archive, and place the files-cli binary file into any directory listed in your $PATH environment variable.
curl -L https://github.com/Files-com/files-cli/releases/latest/download/files-cli_macOS_64bit.tar.gz | tar zxv
sudo mv ./files-cli /usr/local/binFor Linux systems that support RPM, such as Red Hat Linux, Fedora Linux, CentOS, openSUSE, Oracle Linux, and others, use the RPM Package Manager to install the CLI App:
curl -L https://github.com/Files-com/files-cli/releases/latest/download/files-cli_linux_{ARCH}.rpm -o files-cli.rpm
sudo rpm -i ./files-cli.rpmFor Debian based systems, such as Ubuntu Linux, use the APT Package Manager to install the CLI App:
curl -L https://github.com/Files-com/files-cli/releases/latest/download/files-cli_linux_{ARCH}.deb -o files-cli.deb
sudo apt install ./files-cli.debLearn how to use the Files.com CLI App by reading the documentation.
Explore the files-cli code on GitHub.
You can get usage information for the files-cli program and any of its commands or subcommands by using the
--help option.
files-cli --help
files-cli folders --helpThe Files.com Support team provides official support for all of our official Files.com integration tools.
To initiate a support conversation, you can send an Authenticated Support Request or simply send an E-Mail to support@files.com.
If you're driving files-cli from an AI agent — or building an agent that uses it — start with these:
| Resource | Description |
|---|---|
| CONTEXT.md | CLI-wide invocation contract: authentication, global flags, output format, error conventions. |
| skills/ | SKILL.md packages — one per top-level CLI command (Bundles, Users, Files, …), grouped by category. |
| skills/INDEX.md | Full index of skills. |
| agents/tool-catalog.json | Machine-readable catalog of the API resource commands and their parameters, generated from the API schema. |
| agents/error-catalog.json | Machine-readable catalog of known error types with HTTP codes. |
Core invocation:
files-cli <domain> <subcommand> --format json --non-interactive [flags...]- Pass
--format jsonso output is structured (the defaulttableis for humans). - Pass
--non-interactiveso the CLI never blocks on a prompt. - Exit code
0is success. Non-zero is failure; read diagnostics from stderr.--format jsondoes not provide a uniform JSON error envelope.
For Claude Code, Codex, or any agent that supports filesystem-loaded skills, point the skills directory at skills/. For agents without skill loading, load the relevant SKILL.md directly into context based on the task at hand.
The installed binary can also describe itself, offline and without credentials, matched to its version:
files-cli commands # top-level commands and groups
files-cli commands search share link # find commands by keyword
files-cli commands describe folders list-for --format json
files-cli workflows show recipe-searching-for-files
files-cli workflows show filescom-permissionscommands describe also reports a hint about the command's effect (read_only, mutating, or destructive; guidance, not an enforced guarantee), the fields of the records it prints for use with --fields, and links to the guides for the command. See CONTEXT.md for details.
To read a long list a page at a time, add --json-envelope to a list command. It prints {"has_more", "next_cursor", "data"} for one page; pass next_cursor back with --cursor to continue. Without the flag, --format json output is unchanged. See CONTEXT.md for details.
There are two ways to authenticate: API Key authentication and Session-based authentication.
Authenticating with an API key is the recommended authentication method for most scenarios, and is the method used in the examples on this site.
To use an API Key, first generate an API key from the web interface or via the API or an SDK.
Note that when using a user-specific API key, if the user is an administrator, you will have full access to the entire API. If the user is not an administrator, you will only be able to access files that user can access, and no access will be granted to site administration functions in the API.
export FILES_API_KEY="YOUR_API_KEY"set FILES_API_KEY="YOUR_API_KEY"files-cli --api-key=YOUR_API_KEY folders list-for ''
## After the key has been provided once it will be written to the files-cli configuration file.
## You do not need to include the same API key for future commands.Don't forget to replace the placeholder, YOUR_API_KEY, with your actual API key.
You can also authenticate by creating a user session using the username and password of an active user. If the user is an administrator, the session will have full access to all capabilities of Files.com. Sessions created from regular user accounts will only be able to access files that user can access, and no access will be granted to site administration functions.
Sessions use the exact same session timeout settings as web interface sessions. When a session times out, simply create a new session and resume where you left off. This process is not automatically handled by our SDKs because we do not want to store password information in memory without your explicit consent.
To log in to the CLI App with your username and password, you must first configure the CLI App with information about your Files.com account.
Once you've specified your subdomain information and username, you do not need to specify it again for subsequent uses of the CLI App.
You will be prompted for the password when a command is run that requires authentication. Once the password is entered, subsequent calls will not require a password, unless the session is no longer valid (ie, expired).
files-cli config set --subdomain SUBDOMAIN --username motor
files-cli folders list-for ''
> password: vroomOnce the password has been verified by the first run command, all subsequent commands can be run and the current verified session will be used.
You can also provide an existing session ID directly with --session-id, or store it with files-cli config set --session-id.
files-cli folders list-for ''
## Or use an existing session ID directly.
files-cli --session-id=YOUR_SESSION_ID folders list-for ''
## You can also store the session ID for future commands.
files-cli config set --session-id YOUR_SESSION_IDUser sessions can be ended by calling sessions delete.
files-cli sessions deleteThe files-cli client can be configured by running files-cli config set.
You can use the --profile option to modify the configuration of a specific
profile. That same option can be used to specify the profile to use when
interacting with Files.com. This allows you to use multiple Files.com accounts
without needing to reauthenticate when switching between them.
files-cli config set --profile firstaccount --username FIRSTUSERNAMESet this to the full https:// URL of your Files.com subdomain (e.g. https://MY-SUBDOMAIN.files.com).
This is not required in most cases, but one benefit of setting it is that it ensures that authentication failures will be logged to your site's API logs. Without setting this, we won't know which site to associate the authentication failure with, and it won't be logged to your site's API logs.
This is always required if your site is configured to disable global acceleration.
This can also be set to use a mock server in development or CI.
files-cli config set --endpoint https://MY-SUBDOMAIN.files.com
## alternatively
files-cli config set -e https://MY-SUBDOMAIN.files.comSet the maximum number of concurrent connections.
files-cli config set --concurrent-connection-limit 5
## alternatively
files-cli config set -c 5Store an existing user session ID for CLI authentication. You can also provide a session ID for a single command with --session-id.
files-cli config set --session-id YOUR_SESSION_IDScope every command to a specific Workspace by storing its ID. You can also scope a single command with --workspace-id.
files-cli config set --workspace-id YOUR_WORKSPACE_IDSet default format for displaying resources.
The supported formats are:
- json
- csv
- table
For the json format you can specify either pretty or raw after a comma (,).
For the table format you can specify a style (interactive, light, dark, or bright)
and/or a direction (vertical or horizontal) by adding those after commas (e.g. table,dark,horizontal).
files-cli config set --format json,raw
files-cli config set -f table,bright,verticalSeveral of the Files.com API resources have list operations that return multiple instances of the resource. The List operations can be sorted and filtered.
To sort the returned data, use the --sort-by parameter.
--sort-by="field=asc"Valid directions are asc and desc.
For historical reasons, and to maintain compatibility with a variety of other cloud-based MFT and EFSS services, Folders will always be listed before Files when listing a Folder. This applies regardless of the sorting parameters you provide. These will be used, after the initial sort application of Folders before Files.
files-cli users list \
--sort-by="username=asc"Filters apply selection criteria to the underlying query that returns the results. They can be applied individually or combined with other filters, and the resulting data can be sorted by a single field.
Each resource supports a unique set of valid filter fields, filter combinations, and combinations of filters and sort fields.
| Flag | Type | Description |
|---|---|---|
--filter="field=value" |
Exact | Find resources that have an exact field value match to a passed in value. (i.e., FIELD_VALUE = PASS_IN_VALUE). |
--filter-prefix="field=value" |
Pattern | Find resources where the specified field is prefixed by the supplied value. This is applicable to values that are strings. |
--filter-gt="field=value" |
Range | Find resources that have a field value that is greater than the passed in value. (i.e., FIELD_VALUE > PASS_IN_VALUE). |
--filter-gteq="field=value" |
Range | Find resources that have a field value that is greater than or equal to the passed in value. (i.e., FIELD_VALUE >= PASS_IN_VALUE). |
--filter-lt="field=value" |
Range | Find resources that have a field value that is less than the passed in value. (i.e., FIELD_VALUE < PASS_IN_VALUE). |
--filter-lteq="field=value" |
Range | Find resources that have a field value that is less than or equal to the passed in value. (i.e., FIELD_VALUE <= PASS_IN_VALUE). |
Use --filter-by for client-side wildcard filtering after records are fetched.
--filter-by="field_name=*.jpg"
files-cli users list \
--filter="not_site_admin=true"files-cli users list \
--filter-prefix="username=test"files-cli action-logs list \
--filter-gteq="created_at=2024-01-01"files-cli users list \
--filter="not_site_admin=true" \
--filter-prefix="username=test" \
--sort-by="username=asc"files-cli folders ls some/path \
--filter-by="path=*.jpg"Files.com preserves the spelling of file and folder paths while comparing them using shared case and Unicode rules. Use the SDK comparison helpers when matching paths locally.
Files.com uses case-insensitive path matching based on its fixed Unicode comparison map.
For example, the following paths have the same comparison key:
| Path Variant | Comparison Key |
|---|---|
Documents/Reports/Q1.pdf |
documents/reports/q1.pdf |
documents/reports/q1.PDF |
documents/reports/q1.pdf |
DOCUMENTS/REPORTS/Q1.PDF |
documents/reports/q1.pdf |
This behavior applies across:
- API requests
- Folder and file lookup operations
- Automations and workflows
See also: Case Sensitivity Documentation
Use / between folder and file names, without leading or trailing slashes. SDK normalization helpers convert backslashes to /, remove duplicate separators, and discard exact . and .. components. Discarding .. leaves the preceding folder name intact.
| Input | Normalized path |
|---|---|
folder/subfolder/file.txt |
folder/subfolder/file.txt |
/folder/subfolder/file.txt |
folder/subfolder/file.txt |
folder/subfolder/file.txt/ |
folder/subfolder/file.txt |
//folder//file.txt |
folder/file.txt |
folder/../file.txt |
folder/file.txt |
Files.com compares paths using a fixed mapping shared by the server and SDKs. It treats case and many accent differences as equivalent: Résumé.txt and resume.txt identify the same file, as do q followed by a combining acute accent and q. The mapping also handles other equivalences, such as Hiragana and Katakana. Lowercasing or applying a standard Unicode normalization form alone does not reproduce these rules.
SDK comparison helpers normalize path separators and dot segments, then apply the bundled versioned comparison map. The shared examples give exact comparison results for integrations that implement their own matching. The map uses hexadecimal Unicode scalar values as keys: a missing entry preserves the character, an empty replacement removes it, and other replacements may contain several characters. Apply each replacement once without normalizing or lowercasing the result again.
Use comparison results only for matching. Send the original path spelling in API requests and preserve it for display and local filenames; comparison results can have a different spelling or length.
Trailing whitespace is significant for comparison. report.txt and report.txt are different file paths, and SDK helpers preserve spaces, tabs, and newlines. Folder names cannot end in whitespace. See Unicode Normalization for the complete path rules.
A Workspace groups files, users, groups, Partners, integrations, and workflows within a Files.com Site. An integration can provision a Workspace for a department or project and delegate its operation to a team without making that team Site Administrators. Every Site has a Default Workspace, with ID 0; additional Workspaces have their own IDs and root folders.
Account membership, request context, and permission grants serve different purposes. Creating an account in a Workspace determines where it belongs. Selecting a Workspace determines which resources a request operates on. A permission grant determines what the caller can do there. Selecting a Workspace never grants access to it.
A user's or group's workspace_id identifies the Workspace the account belongs to. Accounts belonging to a Custom Workspace stay within it. Default Workspace users and groups can receive permissions in one or more Custom Workspaces while keeping their existing accounts in Workspace 0.
| Account | Workspace Administrator assignment | Scope |
|---|---|---|
| User belonging to a Custom Workspace | Set the user's workspace_admin to true. |
That user's own Custom Workspace. |
| Default Workspace user | Create an admin Permission for the user on a Custom Workspace's root folder. |
Each Custom Workspace with a root grant. |
| Default Workspace group | Create an admin Permission for the group on a Custom Workspace's root folder. |
Every member inherits administration of each Workspace with a root grant. |
workspace_admin is not a summary of a user's effective administrative access. A Default Workspace user can administer a Custom Workspace through a direct or group root grant while their workspace_admin remains false. Groups have no workspace_admin field. See Users and Groups for account fields.
An admin grant on the Custom Workspace root provides full Workspace Administrator authority over its files, users, groups, Partners, workflows, and integrations. An admin grant on a subfolder provides Folder Admin authority over that folder and its descendants; it does not provide Workspace administration. Other permission levels provide their corresponding folder access without Workspace administration. Permissions defines the levels.
Site Administrators manage cross-Workspace assignments to Default Workspace accounts. Workspace Administrators manage accounts and permissions within their own scope. Site Administrators retain access to every Workspace; adding a Workspace grant does not narrow Site Administrator authority. The product documentation explains the administrator's operational scope and site-wide controls.
You can include the X-Files-Workspace-Id REST header to select a Workspace for a request. SDK request options and CLI configuration send that same selection. When a Workspace is selected, Workspace-scoped resources are listed, created, and changed within that context, and ordinary paths are relative to its root.
A resource's workspace_id request field describes the resource's Workspace membership. It is separate from the SDK's Workspace request option or REST header. Creating a Workspace-scoped resource in a Custom Workspace defaults its workspace_id to the selected Workspace; a mismatching membership value is rejected with not-authorized/insufficient-permission-for-params.
Selecting another Workspace with an API key requires a Full Access key created in the Default Workspace. A user key follows that user's current access, including group permissions. A site-wide Full Access key created in the Default Workspace has Site Administrator authority in every Workspace. A Files Only key stays in its creation Workspace, even if its user has cross-Workspace access. Any key created in a Custom Workspace stays within that Workspace. Selecting another context with these confined keys is rejected with bad-request/invalid-workspace-id-header.
An account belonging to a Custom Workspace is scoped there when it authenticates normally. For a Default Workspace user, explicitly select the intended Workspace for an integration rather than relying on an interactive login preference. API Keys and Authentication cover credentials.
The Files.com CLI supports workspace scoping by using --workspace-id for a single command. Configure subsequent commands by running files-cli config set --workspace-id.
The adjacent scoping example uses a credential authorized for the selected Workspace. A group member uses their own Full Access user key from the Default Workspace; the Site Administrator credential used to assign the grant is not needed for their day-to-day work.
files-cli --workspace-id 123 folders list-for ''
files-cli config set --workspace-id 123
files-cli folders list-for ''An operations team already represented by a Default Workspace group can administer a Custom Workspace through one root Permission. The group and its members stay in the Default Workspace, so the same team can receive different access in other Workspaces.
First retrieve the target Workspace and Group IDs as a Site Administrator in Workspace 0. The examples use Workspace 123, group 456, and member user 789; replace them with your own IDs. Confirm that the group belongs to Workspace 0 and that the intended user is a member.
Create the Permission using a Default Workspace Full Access site-wide key or a Full Access user key belonging to a Site Administrator. Keep the request context at 0 and use the qualified root path _/Workspaces/123. Set group_id to the group's ID, permission to admin, and recursive to true. Save the returned Permission id for later removal. For an individual Default Workspace user, use user_id instead of group_id.
For a Default Workspace group, a Site Administrator can also select Workspace 123 and use an empty path to grant access to its root. The qualified path in Workspace 0 works for both Default Workspace users and groups and keeps the account scope and target Workspace explicit. Appending a subfolder to the path would grant Folder Admin access instead of Workspace Administrator authority.
After the grant, make a request as the member, using their own credential with Workspace 123 selected, such as listing that Workspace's root folder. That member can work with the Workspace's files and perform Workspace Administrator operations, such as managing its users, Partners, and integrations. A Site Administrator's successful request does not establish that the member has the intended access.
files-cli --workspace-id 0 workspaces list
files-cli --workspace-id 0 groups list
files-cli --workspace-id 0 permissions create \
--path '_/Workspaces/123' --group-id 456 \
--permission admin --recursiveList the member's Permissions with user_id and include_groups=true to include grants inherited through group membership. Listing only direct user grants can miss the Permission that provides Workspace administration. In Workspace 0, the Custom Workspace root appears as _/Workspaces/123; in Workspace 123, paths are relative to that root. Inspect the root path and permission=admin, rather than treating the user's workspace_admin field as their effective administrative access.
Permission lists show individual grants, rather than a single flag for effective administrative access. Membership in several groups combines their access. A Permission using group_ids instead of group_id requires membership in all the specified groups; it is not a shorthand for assigning the same grant to several independent groups.
Removing a member ends access received through that group. Deleting the root Permission ends the group's Workspace Administrator grant for every member. These changes leave independent direct and other group grants in place, so review all applicable grants when withdrawing access. Default Workspace user API keys follow those permission changes without being recreated.
Group membership maintained through SCIM follows the same rule. A Group Admin allowed to add members can give those users the group's existing Workspace Administrator access. Choose who manages the group with that authority in mind.
Delete the Permission by its returned id as the Site Administrator in Workspace 0. The removal examples use Permission ID 9001; replace it with the ID returned by your create request. Permissions are created and deleted, rather than updated in place. If narrower folder access is still needed, assign it explicitly; deleting a broad grant does not restore narrower grants it previously replaced.
files-cli --workspace-id 0 permissions list --user-id 789 --include-groups
files-cli --workspace-id 0 permissions delete --id 9001The Files.com CLI supports localized responses by setting the files-cli config set -l option. The language can be reset by using files-cli config reset -l.
When configured, this guides the API in selecting a preferred language for applicable response content.
Language support currently applies to select human-facing fields only, such as notification messages and error descriptions.
If the specified language is not supported or the value is omitted, the API defaults to English.
files-cli config set -l esThe Files.com CLI will detect errors coming back from the API and provide a detailed message to the current output explaining the cause of the error.
Errors fall into two basic categories:
- General Usage Errors - errors that result from incorrect usage of the CLI tool
- API Response errors - errors returned from the Files.com API.
files-cli BADCOMMAND
Error: unknown command "BADCOMMAND" for "files-cli"
Run 'files-cli --help' for usage.
files-cli folders list-for /BADFOLDER
Error: Not Found - `Not Found. This may be related to your permissions.`
To understand the types of errors that come back from the Files.com API and will be displayed by the CLI, see the Rest API Errors.
If you are running scripted operations, you can have the CLI send a report of
the operation including the Success/Failure status as well as a log of every
run. To do this add the flag --send-logs-to-cloud.
The operation logs will be made available in the web interface at Settings > Logs > External logs.
Files.com publishes a mock Files.com API server, which is useful for testing your use of the Files.com SDKs and other direct integrations against the Files.com API in an integration test environment. It never checks credentials: send any placeholder API key, and never use real Files.com credentials with it.
The server has two modes, chosen when it starts:
- Legacy mode (the default) checks required parameters and parameter types, then returns a fixed example response for each API endpoint. It does not maintain state and it does not deeply inspect your submissions for correctness, which makes it useful for testing basic network operations and JSON encoding for your SDK or API client.
- Simulation mode keeps records, files and folders in memory, so a test can create, list, update and delete resources, upload a file and download the same bytes, and make chosen requests fail, stall or lose their connection on purpose. Requests it does not simulate fail with a clear error instead of returning an example response.
Start the server from its source with Ruby and Bundler. FILES_MOCK_MODE is read once at startup:
leaving it unset or setting it to legacy starts legacy mode, simulation starts simulation mode,
and any other value stops startup with an error. Legacy mode listens on port 4041 on all IPv4
interfaces, and simulation mode on 127.0.0.1:4041.
Simulation mode keeps its state only in the server process. Its control endpoints under
/__files_mock/v1 report when the server is ready, reset it with your fixtures, add fault rules
and return the journal of the requests it received. It refuses work over its limits instead of
truncating it. The README in the source describes all of these, the operations it simulates and
how to configure its limits.
Download the server as a Docker image via Docker Hub.
The image's latest tag moves to whichever server was published last, so it need not include
simulation mode; to run exactly the server the README describes, build the image from the source.
The Source Code is also available on GitHub.
bundle install
## Legacy mode
bundle exec puma
## Simulation mode
FILES_MOCK_MODE=simulation bundle exec pumaBy default, the CLI App will output its data in table format.
You can select the output format by using the --format option. For example,
to specify that the output should be formatted in JSON format, use the option
--format json.
- table (default)
- table,interactive (searchable and scrollable)
- table,dark
- table,bright
- table,light
- table,markdown
- json (human-readable)
- json,raw (compact)
- csv
Values returned by the API, such as file names, can contain terminal
escape sequences and other control characters. Table output always
displays them as escaped text (for example \x1b for ESC) instead of
sending them to the terminal as controls. CSV and text output are escaped
the same way when written directly to a terminal; when redirected to a file
or piped to another program, values are written exactly as returned by the
API so exports stay lossless. Newline and tab characters keep their existing
formatting and are not escaped. JSON output always escapes control characters
as required by the JSON format; on a terminal the remaining DEL and C1
characters are shown as \uXXXX escapes as well, so terminal JSON stays valid
and decodes to the same values, while redirected JSON keeps its exact bytes.
Error messages and --debug=STDOUT logs are escaped the same way when written
to a terminal.
files-cli users list --format=table,interactivefiles-cli folders list-for /path/to/folder --format csvfiles-cli folders create --path /path/to/folder/to/be/created --format=json,rawfiles-cli users list --format=table,darkYou can configure a preferred format as the default for a profile.
files-cli config set --profile=interactive --format=table,interactiveYou can customize the output by specifying the fields to include in the
response. Simply use the --fields option followed by a comma-separated list
of the desired field names.
files-cli folders list-for --fields path,type --format json[{
"path": "document.docx",
"type": "file"
},
{
"path": "other",
"type": "directory"
}]