Intro to platform integration

This introduction is designed to help you understand different ways of integrating MASV into your applications and workflows — and how to choose between them.

Four ways to integrate with MASV

MASV is a file transfer platform that offers multiple mechanisms to ingest content for upstream processing and to egress content for downstream workflow steps or users.

The integration methods described here are designed to be embedded into applications, workflows, and media/data pipelines.

Each of the integration patterns described below links to a corresponding tutorial.

Pattern 1 — MASV Portal for intake

For receiving files from external contributors, this is the quickest and easiest way to get started by leveraging MASV UI components. The tutorial includes:

• Hosted, embedded, and custom-UI portal variants.
• Portal creation and configuration via API.
• Cloud connections for auto-routing to Amazon S3, Google Cloud Storage, and other destinations.
• Webhook-driven processing and dynamic portal lifecycle management.

Pattern 2 — Embed MASV uploader

For applications that own the UI, this method provides a more white label style experience. The tutorial includes:

• How to configure the front-end/back-end split.
• MASV Web Uploader SDK setup.
• Package session creation, file collection, progress events, and webhook-based post-upload handling.
• Security framing (API key stays server-side; only the package token reaches the browser).

Pattern 3 — MASV Agent-based automation

For servers, NAS devices, and pipelines, this method uses an installed agent and storage gateway. This tutorial includes:

• MASV Agent installation.
• Startup flags.
• Authentication for team vs. portal uploads.
• CLI and local REST API command pairs.
• Upload lifecycle states.
• Download automation.
• Storage Gateway context.

Pattern 4 — Direct MASV API integration

For environments where the MASV Agent or Web Uploader SDK can’t be used.

Caution

To ensure optimal performance of a direct API integration, we recommend that you contact support@masv.io for guidance.

This tutorial includes:

• Full seven-step upload lifecycle — create package, register file, initiate multipart upload in cloud storage, get chunk URLs, upload chunks, finalize file, finalize package.
• The create_blueprint pattern.
• ETag tracking.
• Critical ordering warnings.

Basic steps

Whether you’re building a custom upload experience, automating content delivery into storage, or integrating MASV into an existing MAM or DAM system, every integration follows the same fundamental model:

1. Content enters MASV through a portal, the Web Uploader, the MASV Agent, or an API-driven workflow.
2. MASV creates and manages a package that represents a managed unit of transfer.
3. Metadata and workflow state are associated with the package.
4. Files are delivered to recipients, storage destinations, or downstream systems.
5. Events generated by the transfer lifecycle can trigger additional automation.

Understanding this model is the key to understanding the rest of the platform.

How MASV is structured

Before choosing an integration pattern, it helps to understand that MASV separates two distinct responsibilities:

The control plane is the MASV REST API. It manages your teams, portals, packages, links, and metadata. Every portal you create, every package you track, and every notification you configure are managed through the control plane. Your application server speaks to the control plane using an API key.

The data plane is responsible for moving the actual file bytes. This is handled by MASV’s transfer infrastructure — either through the MASV Agent, the Web Uploader SDK, or direct API upload calls. Files travel to and from MASV’s cloud storage infrastructure, chunked and accelerated, independent of the control plane.

In most integrations, your back end orchestrates the control plane while the MASV Agent or Uploader handles the data plane. Understanding this separation makes it much easier to determine which integration pattern fits your situation.

How to choose an integration pattern

The best integration strategy depends on where workflow ownership resides.

• If your application owns the user experience, use the Web Uploader and Web Downloader SDKs.
• If external contributors need a managed submission experience, use MASV Portals.
• If your application owns workflow state and orchestration, integrate with the MASV RESTful APIs.
• If storage infrastructure is the source or destination of content, use MASV Agent and Integrations.
• When automation is required, use Webhooks.

Most production deployments eventually combine several of these patterns. A typical media workflow may use portals for inbound delivery, Cloud Connections for storage routing, Webhooks for automation, and the API for workflow orchestration. Because all these components ultimately operate on the same package lifecycle, they can be combined without introducing additional workflow models for developers to learn.

Pattern	Best for	Data plane	Who initiates the transfer?
MASV Portal for intake	Receiving files from external collaborators, clients, or contributors; a zero-install upload experience for senders	MASV-hosted portal or embedded portal	Your customer, client, or collaborator
Embed MASV uploader	Custom web applications with your own UI	Web Uploader SDK	End user in the browser
MASV Agent-based automation	Servers, NAS, pipelines, headless environments	MASV Agent	Your application or scheduled process
Direct MASV API integration	Platforms where MASV Agent is unavailable; maximum control	Raw API calls	Your application

Combining patterns

Real-world integrations often combine multiple patterns. Some common combinations:

Inbound + outbound workflow: Use portal for intake (Pattern 1) to receive files from clients, process them on your infrastructure using automation driven by the MASV Agent (Pattern 3), and send the output back to the client using a direct team package via the API (Pattern 4).

SaaS with custom upload UI: Build an embedded upload experience (Pattern 2) for your end users’ inbound workflow. Use Agent-based automation (Pattern 3) for back end to back end file movement, such as delivering processed results to storage systems or partner platforms.

Dynamic portal provisioning: Use the API (Pattern 4 control plane) to programmatically create, configure, and tear down portals (Pattern 1) as part of your project lifecycle management — for example, you can create a dedicated intake portal when a new project opens and delete it when the project closes.