Requesting Files

Inbound transfers turn the WeTransfer model around: you generate a link, send it to someone, and they upload files to you instead of the other way around. Useful for collecting source assets, intake materials, or anything where the file is coming in.

When to Use Request

Inbound transfers are the right tool when:

• You need files from a client and don't want them emailing 200 MB attachments
• Multiple people might upload to the same destination (e.g. "everyone send me your photos for the team page")
• You want to enforce limits on file count, size, or type before files even land in your storage
• The sender doesn't have a portal account — they just need to drop files

If you need ongoing two-way file collaboration, Resources with client folders is a better fit. Inbound transfers are for time-bounded receives.

Creating an Inbound Request

1. Open Transfers from the left sidebar
2. Click Request Files in the top toolbar
3. The Request Files modal opens

Same modal pattern as outbound — basics up top, advanced options collapsible.

Step-by-Step

1. Title (required)

What you're collecting, for your reference. Examples:

• "Brand Assets from Acme"
• "Intake Photos — New Customer Onboarding"
• "Tax Documents — 2026 Year-End"

2. Client (optional but recommended)

Pick the client. Same benefits as outbound — surfaces the request in the client's workspace, scopes the recipient picker, threads the activity history.

3. Recipient Name and Email (required)

Who you're requesting from. The email gets the notification with the upload link.

4. Message (optional)

Context for the sender. Tell them what to upload and why:

• "Please send the high-res versions of the logos approved on Tuesday."
• "Upload all the photos from yesterday's site walk — should be ~30 files."
• "We need your W-9 for our records."

5. Advanced Options

The inbound modal exposes more advanced options than outbound, because you're constraining what the sender can do:

• Expiration (default 1 week)
• Password — sender must enter this before uploading
• Email verification — sender must verify their email before uploading
• Max file count — cap the number of files
• Max file size (MB) — cap each file's size
• Allowed extensions — comma-separated list (e.g. pdf, jpg, png)
• Related portal record — project, ticket, or resource to link this request to

6. Send

Click Create Request. ClientCove:

1. Creates the inbound transfer record
2. Generates a unique upload URL
3. Sends the recipient an email with the link and instructions
4. Adds the request to your dashboard with status Active

Upload Limits

The three limit fields constrain what the sender can do:

Max file count

The maximum number of files they can upload across all upload attempts. Useful for "send me 5 photos" type requests.

Leave blank for no limit (capped only by your cloud storage capacity).

Max file size (MB)

Maximum size of any single file. Common values:

Cloud storage caps still apply

Even with no per-file cap, your cloud provider has its own limits (S3 single-part max is 5 GB; multi-part allows up to 5 TB). For most workflows, 1–2 GB per file is the practical ceiling.

Allowed File Types

To restrict what kinds of files the sender can upload, use Allowed Extensions:

pdf, jpg, jpeg, png

Comma-separated, no leading dots. Case-insensitive. The sender's upload page validates extensions before upload — files with disallowed extensions are rejected client-side with a clear error.

Common patterns:

Server-side validation also runs on upload completion — even if a sender bypasses the client-side check, disallowed files are rejected.

Password & Email Verification

Same options as outbound transfers but apply to the sender instead of the recipient:

• Password — sender must enter the configured password before the upload form unlocks
• Email verification — sender must verify they control the recipient email by entering a 6-digit code

Combine for two-factor protection. See Outbound — Password Protection and Email Verification for the mechanics — they work identically for inbound.

Linking to Portal Records

Same as outbound — link the inbound request to a related project, ticket, or resource. The relationship surfaces:

• On the request itself
• In the linked record's transfer history
• In the audit log

Useful for "this intake request is part of project X" — anyone reviewing project X later sees the inbound transfer and can verify when files arrived.

For projects specifically, there's a much faster path — the project Files tab has a one-click Create Upload Link button that creates a permanent inbound transfer bound to the project, with no expiration and no setup. See Inside Projects, Tickets & Resources — it's probably the feature you actually want when collecting files for a project.

What the Sender Sees

The sender clicks the link in their email and lands on a public upload page. They see:

• Your portal branding (logo, color, image panel)
• The transfer title
• Your message (if set)
• A drag-and-drop upload zone
• The configured limits ("max 10 files, 50 MB each, PDF/JPG/PNG only")
• Their name (pre-filled from the request)
• A confirmation message after successful upload

If password is set, they enter it first. If email verification is on, they verify their email next. Then the upload zone appears.

For details on what the public page actually looks like, see Public Page & Branding.

Receiving Files

When the sender uploads:

1. Files go directly to your cloud storage (browser → bucket via presigned URL)
2. Each upload is recorded in the transfer's files list
3. Audit log entry is created with IP and timestamp
4. You get notified (in-portal + optional email)

The sender can upload in multiple sessions until the transfer expires or they hit the file count limit — they don't have to do it all at once.

After each upload, they see a confirmation that the file is received and a list of what they've uploaded so far.

Notifications on Upload

By default, you (the creator) get notified on each file upload:

• In-portal notification with the file name and upload time
• Optional email notification (per your preferences)

For high-volume requests, consider toggling email notifications off and just checking the dashboard periodically — otherwise you'll get an inbox flood for a 50-file upload.

Reviewing Uploaded Files

Open the inbound transfer's detail view in the dashboard. You'll see:

• Status banner with expiration countdown
• Sender info
• All uploaded files with per-file:
  • Filename and size
  • Upload time
  • Download button (download to your computer)
  • Preview button (for images / PDFs)
• The audit log of all sender activity (verifications, uploads, IP)

From here you can:

• Download all files as ZIP
• Move files into a related portal record (e.g. attach to the linked project)
• Delete unwanted files (they're removed from cloud storage)

Closing a Request

When you've received what you need (or the request was abandoned):

Cancel — stop accepting uploads

1. Open the request detail view
2. Click Cancel Transfer
3. Confirm

The upload page shows "this request is no longer accepting uploads" to anyone who tries. Already-uploaded files stay accessible to you.

Delete — remove the entire request

1. Click Delete Transfer (admin/editor only)
2. Confirm

Removes the transfer record, the audit log entries, and the uploaded files from cloud storage. Irreversible.

For most workflows, cancel is the right action when a request is done — keeps the file history available.