The Gateway Transfers Console

Updated Jul 26, 2026

Hosted File Gateway

The Gateway Transfers Console

The Transfers tab is the record of every file that has crossed the gateway in either direction. Reading needs Builder or Viewer; replay needs DataMagik - Builder.

Summary counters and the retention and storage line

Transfer rows showing path, size, handler, status, expiry and source address

Statuses

Status	Means	Do
received	Stored and recorded, but nothing was queued — normally because no processing queue is available.	Investigate; replay once it is back.
queued	Matched a route and is waiting for a worker.	Nothing. Refresh.
processed	The handler ran and reported success.	Nothing.
duplicate	These exact bytes were already delivered by this principal. Not reprocessed. The note names the original.	Usually nothing — a partner re-sent.
unrouted	Stored safely, but no route claimed the path.	Add a route, then replay.
failed	The handler ran and failed — or a script rejected the document.	Read the reason in the detail panel.
refused	The endpoint would not accept the upload at all — today, storage quota. The only status where a partner's file was turned away rather than stored.	See Limits.

A duplicate row shows no handler, because dedup happens before routing — DataMagik never decided what to do with it, on purpose.

Filters

Direction (received from partners / staged for collection), status, and handler. "Show me failed OCR from today" is two dropdowns.

The status worth putting on a dashboard is refused. It is the only one where a partner's delivery did not land at all, so it is the one that turns into a phone call.

The outcome panel

Click any row.

An expanded transfer showing metadata, artifacts, the script run status and the JSON it returned

The header carries status, handler, size, protocol, the virtual path the partner used, the storage key, the SHA-256 and the time. Below it, Artifacts shows what the handler produced:

EDI — the transaction sets and their actions, linked to the EDI console.
Script — the run status, how long it took, anything it returned, and its console output.
OCR — the extracted fields, kept on the transfer itself.
Lookup load — how many rows were imported and which were skipped, with reasons.
Store — that the bytes were stored.

The stored object is the source of truth, and the receipt outlives it. Once the retention window passes, the file is deleted but the row stays — so "what became of the file that partner sent last quarter?" is answered with "deleted on schedule on the 17th" rather than with silence.

Replay

Replay through the pipeline re-queues the stored file. It re-resolves the route rather than trusting the original decision, so a rule you fixed afterwards actually takes effect. The stored object is untouched.

Use it after: adding a route for an unrouted file, fixing a script that failed, correcting an extraction profile, or registering the trading partner an EDI file needed.

Replay refuses if still nothing matches the path, naming the path so you can see what to write a rule for. It is also only available on inbound transfers — on an outbound staged file it would mean nothing, so it is hidden.

Outbound transfers

Files you have staged for a partner to collect appear with direction out. Staging and collection are recorded separately, and a "Collected" line appears once the partner actually downloads it — which is the question an operator chasing "did they get it?" is really asking.