Processing file data in Zapier Code step using JavaScript

I have a workflow where I’m getting files through a Zapier trigger that connects to BrickFTP. After that, I want to use a JavaScript code step to handle the file data and extract information from CSV format.

I’m passing the File output from the BrickFTP step as an input to my code block, but I keep running into issues when trying to access the actual file contents.

Here’s my basic code setup:

console.log(`File data received: ${inputFile}`);
return {
  result: inputFile,
}

But when I run a test, I get this error message:

Oops! Something went wrong with the javascript execution. :-( Error: 
[LazyFile] (3587 bytes) https://zapier.com/engine/hydrate/691575/.eJwtkFFrwjAUhf_KuM9i1mq3WRhjohSERjaqw76ULL2apG3aJVFR6X9fKr4evnu-w72B1NYxzbGQJcRh9BZFs2A6gr3Euiw0axBiKPFU7GWNMAIukFdFhReIX2ZB9Br5qNUOtSvcpRtg6qnqzMzBQnyDo6l9JpzrbEwI67rxr5G82rtuzNvGB5IYtI6cAjIYLCFSE-eTMbenD8adbPW7wVIa5M43PySPNQ065i39CAz-Hf3VoBTISjR3--fRidbIKxtq_NmcWcmf0uthQputyrPlOVfLyU5tAqpok_5spnSxklTNZZ7x53Um1DrZql0mGprsLrlKPT-vafItUrUSNPyaeFakYRqtF90U-vsi0fpPQrLMoO_7f_ftdsQ:1do4Qj:pEkOihXff9eAzu8eLyTpN378vgI/ is not JSON serializable

It seems like the file input is coming through as some kind of lazy-loaded object instead of actual file content. How can I properly read and process the file data in my JavaScript code step?

That LazyFile object is just Zapier’s way of handling file references without loading everything into memory. You need to hydrate it first to get the actual file contents. Here’s what works:

const response = await fetch(inputFile.url || inputFile);
const fileContent = await response.text();
console.log('File content:', fileContent);

For CSV files, once you’ve got the text content, just split by lines then by commas to parse it. I’ve done this with BrickFTP integrations before and it works great. Zapier doesn’t auto-load file contents for performance reasons, so you have to explicitly fetch from the URL they give you.

Had this exact LazyFile nightmare a few months ago building a data pipeline. The fetch approach works, but you’ll hit more walls with Zapier’s JavaScript limitations.

The real problem? You’re stuck doing manual file parsing and error handling in a constrained environment. What happens when you need different CSV formats or data validation?

I switched our whole file processing to Latenode - night and day difference. You get proper file handling built in, plus you can chain processing steps without wrestling with Zapier’s quirky object types.

With Latenode, just connect BrickFTP, add a CSV parser node, done. No fetch calls, no manual string splitting, no LazyFile nonsense. Data flows clean between steps and you can add transformations visually.

I’ve seen too many Zapier workflows break when file sizes change or formats shift. Latenode handles that automatically and you can actually debug each step.

yeah, lazyfile’s annoying but watch out for empty lines in your csv - they’ll cause parsing errors. brickftp sometimes throws in extra headers too, so check the first few rows before you start processing. i usually clean it up with csvData.trim().split('\n').filter(row => row.length > 0) first.

Been fighting with BrickFTP file processing for years, and the LazyFile dance gets old fast. You can fetch the URL and parse CSV manually, but you’re building a house of cards.

What kills me about Zapier - every file format needs custom parsing. Your CSV works today, but tomorrow someone uploads Excel or changes the delimiter. Now you’re debugging string splits again.

I moved our entire pipeline off Zapier after hitting too many walls. Latenode handles BrickFTP natively with CSV parsers that actually work. No LazyFile objects, no manual fetch calls, no timeouts.

Connect BrickFTP as a trigger, add a file processor, and it detects CSV structure automatically. Need validation? Add filters. Need to transform columns? Drag and drop.

The real win is reliability. Different formats or sizes don’t break your workflow. With Zapier you’re always one edge case from disaster.

Stop wrestling with JavaScript workarounds. Use a platform that handles files properly.

This error happens all the time with Zapier Code steps and file objects. The LazyFile wrapper blocks direct access to file contents - you’ve got to use the fetch method instead.

I ran into the same thing processing invoices from our FTP server. Here’s what I learned: you need to check if your input’s already a URL string or if you need to pull it from the object structure. BrickFTP sometimes passes different formats based on file size.

Here’s what works:

let fileUrl = inputFile;
if (typeof inputFile === 'object' && inputFile.url) {
    fileUrl = inputFile.url;
}

const response = await fetch(fileUrl);
const csvData = await response.text();

// Parse CSV rows
const rows = csvData.split('\n').map(row => row.split(','));
console.log('Parsed rows:', rows.length);

return { processedData: rows };

Watch out for file encoding issues though. If you’re getting weird characters, add encoding detection or force UTF-8 handling in your parsing.

LazyFile objects are how Zapier handles file references without eating up memory right away. You’re getting that error because JavaScript can’t serialize the lazy-loaded object directly.

I’ve dealt with bank statements from our SFTP server before - you need to grab the actual URL first, then fetch the content. BrickFTP triggers can pass file references in different object properties depending on how you’ve got it set up.

Try this:

const fileUrl = inputFile.hydrate_url || inputFile.url || inputFile;
const response = await fetch(fileUrl);
const csvText = await response.text();

// Basic CSV parsing
const lines = csvText.split('\n');
const headers = lines[0].split(',');
const data = lines.slice(1).map(line => line.split(','));

return { headers: headers, rows: data };

One thing I learned the hard way - BrickFTP sometimes dumps metadata rows at the top of files. Make sure your first row is actually CSV headers before you process everything else.

The LazyFile issue comes from how Zapier handles memory management. With BrickFTP files, the file object structure changes based on your trigger setup. Sometimes the URL gets buried deeper in the object.

Don’t jump straight to fetch - first check what you’re actually getting. Log the full object with console.log(JSON.stringify(inputFile, null, 2)). This shows whether you need inputFile.file.url, inputFile.download_url, or just inputFile.url.

BrickFTP files can timeout on large files if you don’t grab them fast enough. I’ve seen workflows break because the hydration URL expired between the trigger and code step. If you’re dealing with big CSVs regularly, add timeout checks and retry logic to your JavaScript.