 What’s New in FlightPath Data 1.1.89

The theme of FlightPath Data 1.1.89 is easier integration. New features make FlightPath more transparent to existing file-based workflows. API development is easier with more specific endpoints and better REST conventions. And new CsvPath Validation Language functions make backend configuration simpler and provide new sources of data.

Transfers

Transfers are post-run exports from the Archive to arbitrary locations. Using transfers you can control your inbound tabular data while still locating incoming files where your downstream systems expect them.
▶ Transfers on named-paths groups (the old csvpath-by-csvpath method continues to be available) using a form
▶ Set any number of transfers triggered by csvpath end-state: valid, invalid, errors, all
▶ All files can be transferred, including named printouts, jinja() output, and Parquet files
▶ Transfer immutable, versioned, source data (from named-files) can be transferred, even though it is a run input, not a run result
▶ Transfers to any storage backend in S3, SFTP, Azure Blob, or Google Cloud Storage

Unlimited SFTP Servers

In the past, each project could have only one SFTP server configuration. That server was used for registrations to bring files in, transfers to send files out, and as a backend for named-files, named-paths, and the Archive. That limitation has been lifted.
▶ Any number of SFTP servers can be added to a named-file for data import and registration
▶ Any number of SFTP servers can be added to a named-paths group definitions for transfers
▶ Separate named-file and named-paths group SFTPs configs, matching on server address and port
▶ Simple form to add named SFTP configs. Add on the fly at any time, including during the import of external data.

FlightPath Server v2

New API version. FlightPath Server v1 is deprecated in favor of a completely new v2. v1 will remain usable and is a configurable option in FlightPath Server. FlightPath Data will use the highest version it knows about, subject to the server making that version available.

v2’s goal is to better conform to REST and HTTP expectations, add new capabilities, fix a small number of outstanding gotchas, and dramatically raise test coverage.
▶ HTTP methods, error codes, and endpoints follow REST conventions
▶ Asynchronous end points for file registration and named-paths group runs
▶ Improvements to admin endpoints and API version support settable in server config

For the rest of 2026 we plan for significant functionality extensions, but only minor fully compatible improvements to existing endpoints.

High Priority Improvements

These are the most impactful other changes in 1.1.89.
▶ Viewing and editing XLSX worksheets is supported with a right-click to select. Edited worksheets must be saved as individual CSV files. We still don’t see FlightPath as an alternative to Excel, but for reasons of productivity, you can now work on worksheets-housed data without needing to switch products.
▶ Updated Find Data Dialog now displays registration or run date-times with the paths of the files found
▶ Generate multiple printout files by printer name using print-mode:separate. This extension to print mode is a big deal for some users. Say you want to generate a run report separate from a line-by-line punch list of errors, now you can create those two separate files, rather than having the two reports concatenated into the same printouts.txt file. This separation in combination with the more capable transfers helps FlightPath fit into existing workflows and more complex business operations.
▶ Register files filtered by regex when registering the contents of a directory
▶ Ability to pass own registration UUIDs into file registrations to enable retrieving the exact-match named-file reference when registering asynchronously. FlightPath Server and other long running processes may need to start a registration and move on to other work, coming back when the registration completes. This capability allows your process to pick up where it left off.
▶ Pass arbitrary metadata into run to be stored with run results. Similar to file registration UUIDs, but going further to enable passing metadata that may be important downstream to custom CsvPath Framework listeners, FlightPath Server, or downstream systems.
▶ New tmp qualifier to limit the data stored in vars.json @myvar.tmp creates an ephemeral myvar variable that will not take up space in vars.json, making it safer for large scale data sets.

New Functions

▶ runtime() — access runtime variables already available to print(), error(), and jinja()
▶ metadata() — access to user-defined csvpath metadata fields declared in the leading comment above a csvpath. This gives you access to a tags-like capability. Metadata fields were already available in run results in the meta.json file.
▶ env() — access environment variables available from the project’s env.json or OS env vars
▶ uuid() — a schema type for line() schemas and a way to generate new UUIDs
▶ select() — selects values from a column of data in a SQL database

New Registration Tokens

Keeping with the theme of easier integration to existing workflows, your templates can now include a set of date/time tokens that can be mixed with static strings and the source path segment indexes.
▶ :day - 01 to 31
▶ :month - 01 to 12
▶ :month_name - January, February, etc.
▶ :year
▶ :hour_24 - 00 to 23
▶ :hour - 00 to 11
▶ :minute
▶ :second

Additional Runtime Fields For print() and meta.json

New runtime indicators and identifiers help you construct output paths, label and report contextually, and identify results in a consistent way.
▶ day, day_of_week, month, month_of_year, hour, hour_of_day, minute, second
▶ run_dir_path, run_dir
▶ run_reference
▶ named_paths_name
▶ named_file_name
▶ run_index - like the identity field that gives the csvpath statement ID or index, but always returning the statement’s index

Quality

▶ Many minor improvements and bug fixes
▶ Over 1000 new tests
▶ Old SFTPPlus integration removed in favor of new FlightPath Server API capabilities created in collaboration with Pro:Atria. SFTPPlus remains a supported and continually tested backend.