Video Concatenation API for Developers: Merge MP4, MOV, AVI via REST

Video Concatenation API for Developers: Merge MP4, MOV, AVI via REST

Video pipelines often receive assets from more than one source. A mobile application may upload MP4, a camera integration may deliver MOV, and an archive may still contain AVI or MPEG. If the next system expects one predictable media file, every integration team ends up solving the same problem: inspect the inputs, normalize them, concatenate them and expose a result that another service can download. VideoConcat provides that capability as an asynchronous video concatenation API over REST.

The endpoint and request model

Authenticated clients submit a multipart request to POST /api/files/start-process. Set actionName=VideoConcat, include two to fifteen video files as file0 through file14, and send parameters=[] and async=true as in the public examples. The API also accepts public URLs in fileUrl, separated by |, and uploads and URLs may be combined. The complete examples and response contract are available in the VideoConcat API documentation.

The initial response is a process record, not the finished media. Save its id and trackingUrl. A client can then poll /api/actions/get-action-infos/{id} with the same Bearer JWT until the process is complete. This model avoids keeping an HTTP request open while video normalization and encoding take place.

Why the asynchronous contract matters

Concatenating several videos is a media job with variable runtime. A short set of compatible clips may finish quickly, while a set of large, long or high-resolution sources needs more work. An asynchronous merge videos API lets your application acknowledge the request, store the process ID, and update its own job state from the status endpoint. A queue worker can finish the operation independently of the web request that started it.

In an integration, treat the returned process ID as a status reference rather than proof of authorization. Keep the authenticated user context on every status and download request, and use the server-provided result links when the job is complete. Do not expose a result merely because a caller knows an integer ID.

A predictable output for downstream systems

Before assembly, VideoConcat normalizes each source to a common media profile. It accepts common formats including 3GP, AVI, FLV, M4V, MKV, MOV, MP4, MPEG, MPG, OGV, TS, WebM and WMV, and different extensions may appear in one request. The normalized video targets a common resolution up to 1920×1080, 30 frames per second, H.264 video and AAC audio. Letterboxing preserves the source framing when aspect ratios differ. A silent audio track is added when an input has no audio.

The successful response exposes one downloadable MP4, which makes the handoff easier for a transcoding queue, asset manager, publishing workflow or customer portal. Your application still needs to validate the business meaning of the clips and decide whether captions, branding or further editing are required. The API solves concatenation and normalization; it is not a replacement for an editorial approval step.

Validation and ownership boundaries

Server-side validation checks the number of inputs, their real media content, MIME information, ownership and limits. Each video is limited to 100 MB and 10 minutes. A complete request is limited to 1 GB and 30 minutes, and it must contain between 2 and 15 videos. These rules are enforced independently of a client’s file extension, JavaScript or declared content type.

That distinction matters in an automated system. A filename such as clip.mp4 is not proof that the bytes contain a valid MP4, and a frontend file picker is not an authorization boundary. Send files belonging to the authenticated account, retain the JWT securely, and handle stable validation errors as input failures rather than retrying them indefinitely. Public URLs should be limited to sources your application is allowed to process.

Usage-based pricing and retry behavior

A successful VideoConcat treatment costs 15 tokens. A validation failure is not billed, which allows an integration to correct cardinality or size mistakes without paying for a failed validation. Your job system should distinguish a rejected request, an in-progress process, a failed processing result and a successful result. Avoid starting a second process just because a polling request timed out; first retrieve the existing process status.

Store the process identifier and use bounded polling with backoff appropriate to your product. When the process reports success, persist the result reference you receive and download it through the authenticated result flow. If your own webhook or queue receives a duplicate notification, make that consumer idempotent as well.

Where to use the API

Typical integrations include assembling clips uploaded by a customer, creating a review copy from camera fragments, preparing a single handoff file for a content management system, or joining a set of public training segments before archiving. A service can accept MP4 and MOV from different upload paths without forcing users to understand FFmpeg or a desktop editor.

For the complete multipart examples, status response and downloadable-result details, read the VideoConcat REST documentation. When your application needs to merge MP4, MOV, AVI or other supported sources into one normalized MP4, the API gives you a small, trackable contract built for asynchronous processing.