Import files from a link

A partner often sends files as a link to a share on a transfer service, rather than as attachments. Forward that email to the project's inbox address, and Final Frame brings the files into the project.

Today it reads IBM Aspera on Cloud public share links (https://<name>.ibmaspera.com/public/files?token=...), downloading over HTTPS. Signiant Media Shuttle, MASV, WeTransfer, Frame.io, Box, Dropbox and Google Drive follow in the same shape.

1. From the Inbox

Open the email in Project details → Inbox. An email carrying a share link shows a Files at a link card under its words: the service and the share.

1. Show the files lists every file in the share with its size, and says where each one would go and why.
2. Choose where the files go (Into Imports or Match to placeholders) and what they are filed as (proxy, master, trailer, audio, subtitles or artwork). The list follows the choice.
3. Import starts it. Each file is an item on the Processing page while it copies.

An email from a sender the project does not know waits in Quarantine. Its card still lists the files; Release and import lets the email in and imports in one step.

Undo on the card takes back what the import filed: files leave Imports, and placeholders get back what they held.

2. From Runner, the API, MCP and the command line

• Runner: "Import the files at the link in Eric's email." Runner shows the checklist with every file, its size and where it goes. Nothing moves until you commit. Undo last action takes it back.
• API: POST /v1/projects/{id}/imports/from-link with messageId (and linkIndex), or url. The answer's statusUrl is the run. POST .../from-link/preview lists the share and writes nothing.
• MCP: the import_from_link tool, with preview: true to list first.
• Command line: ff import-link <projectId> --message <emailId> or --url <link>, with --preview.

Importing needs permission to add files to the project. A link from an email also needs permission to read that inbox.

3. What happens to each file

• It streams from the service into your organisation's landing area, then into your own storage. It never passes through Final Frame's web servers.
• A SHA-256 is taken on the way through and checked against what landed.
• It is virus scanned, as inbox attachments are. Picture and sound files are recognised by their own header and passed over; anything else is read. A file that fails is blocked and named on the card.
• It is filed into the project's Imports, or onto its placeholder when the match finds one. A file that matches no placeholder stays in Imports with the reason.
• Every file is on the project's action log with the service and the share's name.
• A file already in from an earlier import of the project (same name, size and checksum) is skipped, so running an import again only brings what is new.

4. Matching to placeholders

The match reads an episode number from the file name with the project's patterns: S01E03, EP103, _103_ by default. A three-digit number also reads as season and episode (103 is S1 E3). Among the placeholders of the chosen kind for that episode, the language in the name and then the title's name pick one. A placeholder that already holds a file is never chosen, and takes one file per import.

5. The settings

Link sources need permission to configure integrations; the Inbox settings need permission to manage the project's inbox. Every change is on the action log.

Automatic import happens only when all three agree: the project imports from trusted senders, the sender is one of its trusted senders, and the sender's domain is on the organisation's list. Anything else waits for a person to press Import.

6. The link itself

A share link carries a token that opens the share. Final Frame seals it the moment an import starts, holds it only while the import runs (48 hours at most) and then forgets it. It is never written to a log, the action log or an answer, and never shown to Runner.