Delivering outputs (Destinations)

The last step of a Multi FileFeed is shipping the validated output somewhere useful. By the time data reaches a destination, the agent has already done the upstream work: mapping, cleanup, validation against your template. Destinations are about delivery. Multi FileFeeds support four destination types today (SFTP, S3, Google Cloud Storage, Microsoft 365), plus an optional post-validation transform for cases where the destination needs a different shape than the template defines.

Default output formats

When a Multi FileFeed import succeeds, OneSchema produces:

A JSON payload that conforms to the template's column keys and order.
A CSV file that mirrors the same shape, with the template's column keys as the header row.

These outputs are deterministic: given the same input and the same saved version, you get byte-equivalent output on every run.

Post-validation transforms

Sometimes the destination needs a shape that differs from the template. Common reasons:

Your downstream system expects XML or fixed-width TXT rather than CSV.
You want to repartition the output (e.g. one file per region, one file per day).
You need to add a custom envelope around the rows (e.g. a header block plus the rows).

A post-validation transform sits between the Import files transform and your destination. You describe the transformation in natural language and the agent generates the script, or you author it in code. OneSchema runs it on every validated payload before delivery.

Destination types

You can attach one or more destinations to a Multi FileFeed. Each destination runs after a successful import; if one destination fails, the others still run and the failure is surfaced in the run view.

SFTP destination

OneSchema writes the validated file to your SFTP server. Best for:

Partner integrations that consume files rather than APIs.
Legacy systems with batch-style ingest.

Configure SFTP credentials once on the Settings → Connections page; attach the connection to as many MFFs as you like.

S3 destination

OneSchema writes the validated file to your S3 bucket via cross-account IAM role assumption: the same role-chain setup used for Upload from S3, with write permissions added to your IAM role. Best for:

Pipelines where downstream consumers already read from S3.
High-volume ingest where S3 is the standard storage layer.

See Import files into S3 from Multi FileFeeds for the IAM role setup and a step-by-step walkthrough.

Google Cloud Storage destination

OneSchema writes the validated file to your GCS bucket via service-account impersonation: you grant a OneSchema-provided service account permission to impersonate a service account in your project, scoped to the destination bucket and prefix. Best for:

Pipelines on Google Cloud where downstream consumers read from GCS.
Customers standardized on GCP for storage and analytics.

Microsoft 365 destination

OneSchema writes the validated file to a SharePoint document library or OneDrive for Business folder via delegated OAuth. A user in your tenant connects their account once; a tenant admin separately allowlists each destination site for the OneSchema app with read and write roles (OneDrive for Business doesn't require per-site allowlisting). Best for:

Customers whose downstream consumers read from SharePoint rather than cloud object storage.
Teams that already manage data lifecycles inside Microsoft 365 (versioning, retention, audit) and want OneSchema to deliver into the same surface.

See Connect Multi FileFeeds to Microsoft 365 (SharePoint / OneDrive) for the setup. The destination form has the same Drive type → Site → Drive → Folder picker as the source; the only requirement that's destination-specific is the "roles": ["read", "write"] shape of the per-site allowlist grant.

What about webhook delivery?

Multi FileFeeds don't deliver the validated payload over HTTP today. If your application needs near-real-time notification of a successful import, the supported pattern is:

Configure an event webhook on the MFF (see Using Event Webhooks). OneSchema POSTs a small notification payload — import ID, status, MFF metadata — to your endpoint when the import succeeds or fails.
Pull the validated rows from your endpoint using the Multi FileFeeds API, or read the output files OneSchema already wrote to your SFTP / S3 / GCS destination.

Event webhooks are the notification channel; SFTP, S3, GCS, or Microsoft 365 is the payload channel.

Default vs. custom output filenames

The default output filename incorporates the MFF name, the import ID, and a timestamp, so each run produces a uniquely named output. If your destination needs a specific filename pattern (e.g. partner expects vendor_orders_<date>.csv), configure the filename pattern on the destination.

Failure handling

Destinations can fail for transient reasons (SFTP credentials expire, an S3 bucket policy is updated mid-run, the GCS impersonation chain is briefly unauthorized). OneSchema:

Surfaces the failure in the run view with the underlying error.
Retries based on the destination's configured retry policy.
Optionally fires an event webhook so your alerting can pick it up. See Using Event Webhooks.

If a destination fails permanently, the MFF run is still considered successful at the import boundary: the validated data exists and is browsable in the dashboard. The destination just needs to be re-attempted.

Choosing a destination

A quick decision tree:

Files need to land in S3 because that's where downstream consumers read → S3.
Files need to land in Google Cloud Storage → GCS.
Files need to land in SharePoint or OneDrive → Microsoft 365.
A partner integration speaks SFTP → SFTP.
Your app needs to be notified when an import lands → configure an event webhook for the ping and pull rows via the API.
The downstream shape doesn't match the template → add a post-validation transform in front of any destination above.

You can attach multiple destinations to the same MFF (for example, S3 for the production consumer and SFTP for a partner's batch ingest).