All nodes/Integrations/Files
File Glob
List files matching a glob under the configured store root.
Type in the graph: file_glob
Exec
An error branch can be enabled (expose_error_output) to handle failures on their own path.
Ports can be split into separate execution and data handles.
Try it
Minimal working workflow
- Execute
- Execute + Data
Runs as pasted
When to use it
The node answers “what files are there”. It returns metadata only — path, size and a file reference; nothing is read. The paths then go to File Read in a loop, and the list of references goes to the Files port of Exit or to Send Telegram Message when the files are for the user.
How it works
The pattern is relative to the store root and supports *, ? and **. One subtlety
explains most surprising results: while the pattern contains no **, a star crosses /,
so *.csv also matches reports/2026/q1.csv. As soon as ** appears, a plain * is limited
to a single path segment and recursion is expressed by ** itself (as in reports/**/*.csv).
Depth is capped by Max directory depth: 0 means files in the root folder only, and 20 is the
ceiling. The walk stops at Max results (ceiling 500) and raises the truncated flag. Folders
never appear in the result — only files.
An empty list is a successful run: nothing matched the pattern. A store that is down stays a node failure instead of turning into “the folder is empty”.
Common mistakes
- Expecting a sort order. The order is the store’s traversal order, not name or date. Sort it yourself when it matters.
- Expecting content. Not a single byte of any file is in the output. Reading is a separate step.
- A deep walk over WebDAV. On an external disk the walk issues one request per folder, and
**over the whole root turns into dozens of them. Narrow the pattern and the depth. - An absolute path in the pattern. The pattern is relative; a leading
/matches nothing. - Ignoring
truncated. Hitting the cap looks like an ordinary result: a branch that assumes “these are all the files” silently processes part of them.
Inputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
File storefile_store | Datadata | — | shown when connection_source ≠ "auto" |
Outputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Successoutput | Execute + Dataexecute_data | object | |
Erroron_error | Execute + Dataexecute_data | — | shown when expose_error_output = true |
Filesfiles | Datadata | file |
Configuration
| Field | Type | Default | Description |
|---|---|---|---|
Glob patternpattern | string | * | Relative to the store root; supports *, ? and ** (recursive). Templates are rendered, so a per-session listing is `sessions/{{ variables.sid }}/*.json`. supports templates |
Connection sourceconnection_source | string | auto | Where this node gets its connection. 'From the run context' uses what the platform already knows (the Telegram bot this workflow is deployed to / this workspace's own file store) and needs no wiring. 'External connection' shows the resource port so a config node can be wired into it. Options: |
Subfolderstore_subfolder | string | "" | Optional folder inside this workspace's store to treat as the root, e.g. `reports` or `sessions/{{ variables.session_id }}`. Blank = the store root. supports templates shown when connection_source = auto |
| Advanced | |||
Max resultsmax_results | integer | 200 | Stop after this many paths; the output flags `truncated` when it hits the cap. |
Max directory depthmax_depth | integer | 10 | 0 = files in the root folder only. |
Shared fields
Every node has these three — the platform adds them, not the node author.
expose_error_output— When enabled, show an execution output to connect nodes that run if this step fails.split_ports_in— Show separate execution and data input handles instead of one combined port.split_ports_out— Show separate execution and data output handles instead of one combined port.