younifyd
Menu

Connectors

File Storage Connector

Upload, read, delete, and list files in the platform's own managed file storage, scoped to your store — including batched reads of large CSV/JSON files and file-size limits enforced per store and organisation.

On this page

What this connector is for

Uploads, reads, deletes, and lists files in the platform's own managed file storage — scoped to your store, not a third-party integration, so no connection is needed. Every file you work with here lives at a relative path (e.g. invoices/march.csv) under your store's own namespace.

Uploading or deleting a file through this connector can fire a File Event trigger elsewhere in the store, if that trigger's File Pattern matches the file's relative path — it's the same underlying storage either way. When it fires, the trigger's data includes {{trigger.event}} (created_or_updated or deleted — the storage can't distinguish a brand-new file from an overwrite, so both count as created_or_updated), {{trigger.key}} (the file's relative path), {{trigger.size}}, and {{trigger.eventTime}}.

Most storage-level errors resolve normally, not as a failed step. If the underlying storage call itself fails in a recognizable way (e.g. reading or deleting a file that doesn't exist), Read File, Delete File, and List File typically resolve the step normally with an HTTP-shaped error you can branch on — {{<stepReference>.response.status}} (e.g. 404) and {{<stepReference>.response.data.error}} — rather than failing the step outright. The one guaranteed exception is Upload File's file-size-limit check (below), which always fails the step.

Upload File

Configuring it

  • File Name — required. The relative path to write to, e.g. invoices/march.csv. Can't start with /, can't contain a .. path segment, and is capped at 1024 characters.
  • Body — required. The file's content — plain text, or base64-encoded data for binary content.
  • Content Type — optional, e.g. text/csv, application/pdf.
  • On Conflictoverwrite (default) replaces any existing file at that exact path; createNew instead writes a new file with a timestamp appended before the extension (e.g. march.csvmarch_1700000000000.csv), leaving the original untouched.
  • Retention7, 30, 90, or 365 days, or never (default). After the chosen number of days the file is automatically deleted; never keeps it indefinitely.

Size limit: enforced independently per store and per parent organisation, each defaulting to 25MB unless configured otherwise — exceeding either fails the step with an error naming which limit was hit and the actual size involved. This is the one Upload File failure that always fails the step rather than resolving as an error response (see above).

Reading the response

  • {{<stepReference>.response.data.fileName}} — the name actually written (differs from the File Name you set only when On Conflict is createNew).
  • {{<stepReference>.response.data.size}} — bytes written.
  • {{<stepReference>.response.data.ETag}} — the stored object's ETag.

For example, a step named "Save Invoice" (reference saveInvoice) — {{saveInvoice.response.data.fileName}}.

Example

File Name: invoices/march.csv
Body: {{generateInvoiceCsv.response.data.base64Content}}
Content Type: text/csv
On Conflict: createNew
Retention: 90

Delete File

Configuring it

  • File Name — required. The relative path to delete.

Reading the response

  • {{<stepReference>.response.data.success}}true on success. Deleting a path that doesn't exist still succeeds (S3's delete is idempotent) — this isn't a reliable way to check whether a file existed first; use List Files for that.

For example, a step named "Remove Processed File" (reference removeProcessedFile) — {{removeProcessedFile.response.data.success}}.

Example

File Name: invoices/march.csv

List Files

Configuring it

  • Prefix — optional. Limits results to files whose relative path starts with this (folder-like), e.g. invoices/.
  • Max Files — 1 to 1000, default 1000.
  • Continuation Token — pass a previous call's nextContinuationToken to fetch the next page.

Reading the response

  • {{<stepReference>.response.data.files}} — an array of { fileName, lastModified, size, ETag }.
  • {{<stepReference>.response.data.isTruncated}}true if more files exist beyond Max Files.
  • {{<stepReference>.response.data.nextContinuationToken}} — present when isTruncated is true; pass it back as Continuation Token for the next page.

For example, a step named "List Invoices" (reference listInvoices) — {{listInvoices.response.data.files}}.

Example

Prefix: invoices/
Max Files: 100

Read File

Configuring it

  • File Name — required unless Cursor is set. The relative path to read.
  • Formatraw (default, base64 content as-is), json (parsed; a top-level array becomes batchable rows), csv (parsed rows, batchable), or xml (parsed into a JSON object tree — never batched, always returned whole in one call).
  • Cursor — pass a previous call's nextCursor to continue a batched read. When set, File Name/Format/CSV options are all ignored — the cursor already carries what's needed.
  • Batch Size — 1 to 5000, default 500. Only relevant for csv or a json file whose top-level content is an array.
  • CSV Has Header Row — default true (first row becomes column names, each row an object); false makes each row a plain array of values.
  • CSV Delimiter — default ,.

Reading the response

The shape depends on Format and whether the content needed batching:

  • raw{{<stepReference>.response.data.content}} (base64 string).
  • xml{{<stepReference>.response.data.content}} (the full parsed object tree, never batched — Batch Size is ignored for xml).
  • json, non-array top level — {{<stepReference>.response.data.content}} (the parsed value).
  • json array or csv, fits within Batch Size{{<stepReference>.response.data.rows}} (every row), .hasMore}} = false, no nextCursor.
  • json array or csv, larger than Batch Size{{<stepReference>.response.data.rows}} (only the first Batch Size rows), .hasMore}} = true, .nextCursor}} (feed back into Cursor to continue), .totalRows}} (the overall count).

For example, a step named "Read Invoice Rows" (reference readInvoiceRows) reading a 2,000-row CSV with the default Batch Size — the first call returns {{readInvoiceRows.response.data.rows}} (500 rows), {{readInvoiceRows.response.data.hasMore}} = true, and {{readInvoiceRows.response.data.nextCursor}}; a Loop step re-runs Read File with Cursor set to {{readInvoiceRows.response.data.nextCursor}} until hasMore is false.

Example

File Name: invoices/march.csv
Format: csv
Batch Size: 500
CSV Has Header Row: true

Also applies here

Step Name

What it's for

Every step in a workflow gets a name — either one you set or a default based on the connector and action (e.g. "Get Order Details", "Send Welcome Email"). It's shown throughout the UI and in your execution history, and it's also the source for the step's Reference — a camelCase identifier auto-generated from the name (e.g. "Get Order Details" → getOrderDetails) — which is what you actually use in {{...}} expressions to read this step's output from later steps. See Step Reference.

Rules

  • Must be at least 2 characters, and 50 characters or fewer.
  • Must be unique within the workflow — reusing a name that's already taken will be rejected, with a suggested alternative (e.g. "Get Order Details 2").
  • Can't be empty.

Tips

  • Prefer a descriptive, human-readable name over a generic one — "Get Order Details" is easier to work with later than "HTTP Request 2", especially once a workflow has a dozen steps.
  • Renaming a step updates every reference to it elsewhere in the workflow automatically.

Step Reference

Syntax

Any input field can reference earlier data using {{expression}}. The expression is evaluated as JSONata — so simple dot-paths and more advanced queries (filters, functions) both work.

Referencing a step's output

Use the step's Reference — a camelCase identifier auto-generated from its Name (e.g. "Get Order Details" → getOrderDetails), shown read-only wherever the step's fields are configured — followed by the field path. Elsewhere in these docs this general pattern is written as {{<stepReference>.field.path}}:

{{getOrderDetails.response.data.id}}
{{getOrderDetails.response.status}}

The raw display name won't work here even though it's what you see in the UI — {{Get Order Details.response.data.id}} isn't valid, since a bare name containing spaces isn't a single JSONata identifier. Always use the camelCase Reference.

You can also reference steps by position instead of by reference:

{{steps[0].response.data.id}}

Referencing trigger data

{{trigger.headers.authorization}}
{{trigger.body.customerId}}
{{trigger.query.page}}
{{trigger.params.orderId}}
{{trigger.method}}
{{trigger.path}}

Referencing workflow variables

{{variables.myVariable}}

See Variables for the full list of variable types and more examples, including connection-type variables.

Referencing runtime variables

A separate, mutable namespace written by the Variable connector while a run is in progress — not the same as the workflow-level variables above:

{{runtimeVariables.myVariable}}

Notes

  • If an expression can't be resolved (a typo in a step name, a field that doesn't exist), it resolves to an empty string rather than failing the workflow — check your execution history if a value comes through blank.
  • Object values are automatically JSON-stringified when interpolated into a string field.

Execution Settings

Fire-and-forget

When enabled, the workflow doesn't wait for this step to complete before moving to the next one. Use it for steps whose result nothing downstream depends on — logging, analytics, notifications — so they don't add latency to the steps that matter.

Continue on error

When enabled, a failure in this step doesn't stop the workflow — execution continues to the next step. The failure is still recorded in the execution history; this just controls whether it's fatal.

Combine the two for steps that are genuinely optional to the outcome: fire-and-forget so they don't add latency, continue-on-error so a failure in them (e.g. an analytics endpoint being briefly down) doesn't take down an otherwise-successful workflow run.

Caching

What it does

When enabled, a step's result is cached for a configurable TTL (time-to-live, in seconds). If the step runs again with the same effective cache key before the TTL expires, the cached result is returned instead of re-running the step.

Configuring it

  • Enabled — turn caching on or off for this step.
  • TTL — how long (in seconds) a cached result stays valid.
  • Cache key template — an expression (supporting the same {{...}} step reference syntax used elsewhere) that determines what counts as "the same call". By default this is based on the step's resolved input; a custom template lets you cache more narrowly or broadly than that.

When to use it

Good candidates are steps that call something slow or rate-limited but return the same answer for the same input within a short window — a lookup against a rarely-changing external system, for example. Skip it for steps whose result must always be fresh (anything involving live inventory, pricing, or payment state).

Locking

What it does

When enabled, only one execution of this step (for a given lock key) can run at a time. If a second execution tries to run the same step while a lock is held, it waits until the lock is released or the hold period elapses.

Configuring it

  • Enabled — turn locking on or off for this step.
  • Lock key — an expression (supporting the same {{...}} step reference syntax used elsewhere) that determines what counts as "the same resource". By default the lock is scoped to the step itself; a custom key lets you lock per-customer, per-order, or any other identifier that needs serialized access.
  • Period — how long (in seconds) the lock is held before it's automatically released, in case an execution doesn't complete normally.

When to use it

Use it whenever concurrent executions could race on the same resource — e.g. two workflow runs both trying to update the same order's status at once. A lock key scoped to the order id ensures only one of them proceeds at a time.