Partners change frequently
Vendors, customers, auditors, artists, labs, and service providers may need access for one delivery rather than ongoing membership.
Secure partner exchange
Exchange large packages with partners without opening a permanent account for every handoff.
RIPTON CLOUD gives internal teams a controlled way to send packages to external recipients and receive partner uploads while keeping identity, expiry, revocation, and package state visible to operators.
External access is narrow, time-bounded, and subject to current package and delivery policy.
Evaluated transfer path
01
Internal team
02
Controlled invitation
03
External partner
04
Approved package / inbox
Workflow example
Send the source package. Receive the partner’s return delivery.
Consider an internal team handing prepared files to a service provider, then receiving the finished package. Outbound delivery and inbound intake use separate access scopes.
- 1
Release the outbound package
Choose the external recipient and supported package controls, including the intended access lifetime. The recipient uses the approved download flow.
- 2
Approve the return path
Invite the provider to a Shared Inbox for the return upload. Keep this permission separate from access to the original package.
- 3
Close and review access
Review delivery state and external activity. Remove the inbox invitation when the relationship ends and verify the applicable expiry or revocation behavior.
Test both a permitted transfer and a denied access attempt. Revocation controls future access; it cannot recall files a recipient has already downloaded.
External collaboration
The partner needs the files—not broad access to the internal platform.
External exchange becomes risky when access is permanent, recipient identity is unclear, links cannot be revoked, or teams cannot distinguish an approved delivery from an informal share.
Upload and download are different risks
Receiving a package and releasing a package need distinct scopes, policies, destinations, and operational review.
Revocation must follow current state
Expired, canceled, blocked, failed, unreleased, or removed resources should not remain usable because an old link still exists.
Workflows
Where the transfer path matters most.
Deliveries · recipients · download policies
Send to an external recipient
Release an approved package through a passcode-protected external flow with package- and recipient-scoped policy checks.
Guest uploads · shared destinations · approval
Receive from a partner
Invite an external collaborator to upload into an approved shared inbox through an expiring invitation flow.
Expiry · revocation · audit identity
Operate the relationship
Resend or rotate invitations, remove access, inspect package state, and review external activity without creating a named employee account.
RIPTON CLOUD in the workflow
Narrow external access that follows current policy.
Possession of a link is not treated as general platform authorization. The exchange flow remains constrained by token scope, resource identity, expiry, and current package or delivery state.
Short-lived external tokens
Approved passcodes or invitations exchange for signed, time-bounded credentials scoped to the intended package operation.
Access-time checks
Package and delivery status, recipient binding, expiry, MFA policy, download limits, and fallback policy are evaluated when access is used.
Invitation lifecycle
Shared-inbox collaborator invitations can expire, be rotated and resent, or be removed before another exchange is allowed.
External audit identity
External activity is recorded as an external actor with package and, where available, delivery or recipient context.
Product boundary
A file-exchange workflow—not a general partner portal.
RIPTON controls access to packages and shared-inbox uploads. It does not claim to provide CRM, contract management, procurement, case management, or a complete extranet.
What it covers
- External package upload and download flows
- Shared-inbox collaborator invitations
- Expiry, removal, package-state revocation, and limits
- Notifications and external audit context
What stays with your stack
- General partner identity lifecycle
- Contract or case management
- Malware-safety guarantees for arbitrary content
- Automatic approval of unknown senders
Evaluation path
Test the complete partner journey.
Verify invitation, authentication, upload or download, notification, audit, expiry, revocation, and support behavior as one end-to-end flow.
- 01
Define the partner
Identify who sends, who receives, the package type, destination, approval owner, and expected access lifetime.
- 02
Exercise the happy path
Run invitation, authentication, transfer setup, delivery, notification, and operator review with representative files.
- 03
Exercise revocation
Test expiry, invitation removal, package cancellation, recipient mismatch, download limits, and invalid credentials.
- 04
Review evidence
Confirm audit identity, events, support visibility, retention, and the responsibilities retained by each organization.
FAQ
Questions technical buyers ask.
Do external partners need permanent RIPTON accounts?
Not for supported guest package and shared-inbox upload flows. External guests are temporary, token-only actors and do not become named users.
Can an old link bypass a canceled package?
A valid token is not sufficient by itself. RIPTON reloads current package and delivery state, and denies blocked, canceled, failed, missing, expired, or unreleased resources.
Does RIPTON scan every uploaded file for malware?
This page does not make a universal malware-scanning claim. Content inspection and quarantine requirements should be mapped to the customer’s validated processing and security controls.
Technical evaluation
Bring one real partner handoff to the demonstration.
We will map the recipient, package, access lifetime, approval, notifications, revocation, and audit evidence around a representative exchange.