Requesting files
Send an upload link so someone outside can deliver files to you.
An upload request lets someone outside the company deliver files to a member through a link that expires. The outsider needs no account, and every file they send is scanned and inspected before the member can open it.
Creating an upload request
A member creates an upload request in the web app, or through the API, with:
- One external email address. Each request has exactly one uploader. To collect files from three people, create three requests.
- An expiry, in the same range as a transfer: 1 hour to 30 days, capped by the tenant's longest allowed expiry, with 7 days as the default.
- An optional message, encrypted at rest and shown to the uploader only after they verify.
The uploader is emailed a link straight away. As with transfers, the email comes from a fixed template in English or Japanese, names the tenant and the member's verified address, and carries no message text. An address on the suppression list, for example after earlier bounces, is refused when the request is created, so the member knows at once that it won't arrive.
Limits
| Limit | Value |
|---|---|
| Uploaders per request | 1 |
| Files per request | Up to 50 |
| Size per file | 5 GB |
| Total size per request | 20 GB |
| Expiry | 1 hour to 30 days, capped by tenant policy |
| Retention of received files | Tenant policy: 1 to 90 days, default 30 |
Uploads are resumable, exactly as for transfers: parts go straight from the browser to encrypted storage, and after an interruption only the missing parts are sent again. Received files count against the requesting tenant's daily upload volume and storage quota, not against anything of the uploader's.
Uploader verification
The uploader proves they control the invited address before they see the message or can upload anything. They open the link, request a one-time code, which goes only to the invited address, and enter it to open a verified session in that browser. A forwarded upload link gives the next person nothing.
The same limits apply as for recipients: a code is valid for 10 minutes and allows 5 attempts, and 20 failed attempts in total lock the uploader out until the member or a tenant admin unlocks them. Unlocking always emails a new link, and the old one stops working. See Recipient verification.
Scanning and inspection
Every received file goes through the same single pass as a sent file: a malware scan and a DLP inspection. Each file is handled on its own, as it finishes.
- Shareable files become available to the member, who is notified that files have arrived and sees any DLP findings on them.
- Blocked files never reach the member. That covers infected files, files whose scan kept failing, files the scanner couldn't inspect when tenant policy blocks them, and files a DLP rule blocks. Both the member and the uploader are told. The uploader is not shown the findings.
DLP rules for received files have only two actions: allow and record, or block. There is no warning to confirm and no approval to request, because those are decisions a sender makes about their own files, and here the sender is outside the company. The message on an upload request is not inspected in v1.
The member downloads received files from the web app, under their own signed-in session. Received files have no download limit. Tenant admins see the request's metadata and finding counts, but not the files.
Retention of received files
Received files are kept for the tenant's retention period, then deleted. The period is set in tenant policy, from 1 to 90 days, and defaults to 30 days. It is counted from each file's own upload, not from the request's creation or expiry, so a file delivered on the last day of a request gets its full retention.
The member can delete a received file earlier. Once deletion is due, the target is that the file's contents are gone from every copy, in both regions and in backups, within 7 days. The audit records about the file remain for their own 365 days.
What expiry and revocation do
An upload request is open until it expires or is revoked. The member revokes their own requests; a tenant admin can revoke any request in the tenant.
| Expiry or revocation does | It does not | |
|---|---|---|
| New uploads | Stops them. The link shows that it expired or was revoked. | |
| Uploads in progress | Stops them from completing. Completion is a server-side step that re-checks the request, so parts sent after a revocation are never assembled into a file, and the leftover parts are cleaned up. | |
| Verified sessions | Ends them at once. | |
| Files already received | Delete them or shorten their retention. They stay available to the member until each file's retention ends. |
Revocation is designed to take effect fast: from 5 seconds after it at the latest, no new upload can start. Expiry is checked against the current time on every call, so the link stops working the moment it expires, not when a background job next runs.
To remove files that have already arrived, the member deletes them. To stop an uploader who was invited by mistake, the member revokes the request.
Source: PRD, Architecture, Data model