Every sender becomes an account
Server logins and shared drives turn each vendor and client into an identity to manage and to clean up.
File upload portal and file requests
Let anyone send you large files without giving them an account.
Vendors, clients, contributors and applicants need to send you large files, and every one of them should not become a user in your system. RIPTON CLOUD gives them a link to upload to, gives you the approval and the record, and keeps the files on storage you control.
Access controls described here are the product's supported flows; plan limits are those published on the pricing page.
Evaluated transfer path
01
External sender
02
Browser upload link
03
RIPTON node
04
Your Shared Inbox
The inbound problem
Receiving is harder than sending, because the other side is not yours.
Sending gives you control of the tool. Receiving means the sender chooses, and the answer is usually an attachment that bounces, a consumer link that expires, or an FTP account someone has to create and later forget to delete.
Nobody owns the destination
Files arrive in one person's inbox or personal folder; when they leave, the route breaks.
No approval, no record
Anyone with the link can upload anything, and nobody can say afterwards who sent what, when.
Workflows
Where the transfer path matters most.
Client materials · contributor submissions · applications
Public upload link for a project
Publish an entry point for one package or one inbox. Senders authenticate for that upload only, with a passcode or an invitation, and never see your internal workspace.
Dailies · vendor deliveries · returns
Shared Inbox for recurring intake
One durable destination for a show, a vendor group or a facility, with managers and members, external collaborators you invite, and access requests you approve or deny.
One-off deliveries · audits · legal handoffs
File request to a named person
Invite a specific external sender with a short-lived upload credential scoped to your inbox, rotate or remove it when the work is done.
RIPTON CLOUD in the workflow
How the portal keeps control
The product earns its place by moving prepared data between endpoints—not by claiming ownership of every system around it.
Scoped, short-lived access
Upload, view, download and inbox upload use distinct scopes. Signed external credentials are time-bounded and rejected when expired, tampered with, or used for another resource.
Approval before upload
Public senders can request access; authorised operators approve or deny before any upload credential is issued.
A destination the team owns
Shared Inbox managers and members, external collaborator invitations you can list, resend, rotate and remove, and notifications when packages arrive.
Large files and folders
Browser uploads through Web Edge handle large files and file-heavy folders; senders with RIPTON Desktop get the accelerated path. Plan limits: 10 GB per file on Free, 100 GB on Starter, none from Professional up.
Revocation that works
Package and inbox state is re-checked when a link is used, so cancelling, expiring, blocking or removing access stops further uploads.
No generic speed promise
Upload speed depends on the sender's link and route. The portal is about control and ownership; the accelerated path is there for senders who install Desktop.
Product boundary
An intake route, not a content library.
The portal collects packages into a destination your team manages. Cataloguing, review, and long-term records stay with the systems built for them.
What it covers
- Public upload links for packages and inboxes
- Invitations, access requests and approvals
- Expiring scoped credentials and revocation
- Received-package visibility and notifications
What stays with your stack
- Anonymous access to the internal product
- Media cataloguing and preview
- Form builders and survey logic
- A universal content-safety guarantee
Evaluation path
Test it from the sender's chair
The right test is an outsider, a clean browser, a large file, and your team seeing it arrive.
- 01
Create the destination
A Shared Inbox for recurring intake or a public upload link for one package, with the approval policy you want.
- 02
Send as an outsider
Open the link in a clean browser, request access if required, and upload a representative file set.
- 03
Try to misuse it
Wrong passcode, expired invitation, another package's link, removed access. Confirm each is refused.
- 04
Review the record
Notifications, package state, sender identity in the audit log, and who approved what.
FAQ
Questions technical buyers ask.
Do senders need an account?
No. They authenticate for the specific upload with a passcode or an invitation and never use a seat. External guests are unlimited on every plan.
Can I approve senders before they upload?
Yes. Public senders can request access to an inbox, and an authorised operator approves or denies the request before an upload credential is issued.
How large can uploads be?
10 GB per file on Free, 100 GB on Starter, and no file-size limit from Professional up. Folders upload as a single package.
Where do the files go?
Onto your transfer node's storage, into the inbox or package your team owns. Nothing is held in a vendor cloud.
Technical evaluation
Give your senders a link, not an account.
Start with one inbox and one outside sender. If it works for them, it works.