Video upload API
A video upload API lets an app move video files from a user's device, or from cloud storage, into a video service for processing. The backend requests an authenticated upload URL, the client sends the file straight to the service, often in resumable chunks, and the service reports progress and fires a webhook when the video is ready to play. A good upload API survives large files, weak mobile networks and dropped connections, and keeps the bytes off your own servers.
How does a video upload API work?
The flow has three parties: your backend, the client and the video service. Your backend calls the upload API with its credentials and gets back a one-time upload URL, often with settings attached, such as the playback policy the new asset should have. It passes that URL to the client. The client, a browser, phone or desktop app, sends the file directly to the service. Your servers never carry the video, which avoids doubling transfer and sizing your backend for upload spikes.
On arrival, the service stores the source and starts transcoding. Your app learns the outcome from webhooks: one when the upload completes, one when encoding finishes and the asset is ready, and one if something fails. For files already in cloud storage, the API usually offers a pull instead. You pass a URL to a file in an S3 or GCS bucket, and the service fetches it server to server.
Resumable vs. single-request video uploads
A single-request upload sends the whole file in one HTTP request. If the connection drops near the end of a large file, the request fails and the user starts again. On a laptop on office Wi-Fi that is rare. On a phone moving between cell towers it is routine.
A resumable upload splits the file into chunks, often a few megabytes each, and sends them in sequence. The service tracks which chunks have arrived. After a dropped connection, a network switch or an app restart, the client asks what is missing and sends only that. Chunking also makes progress reporting accurate and lets uploads continue in the background on mobile. Open protocols such as tus and vendor upload SDKs both implement this pattern. For in-app capture, such as claim inspection videos, dashcam footage or recorded interviews, resumable upload is the difference between a file that arrives and one that is lost.
How do you secure a video upload API?
Uploads are a write path into your storage, so only your backend should hold API credentials. Clients get a short-lived upload URL scoped to one asset, never a key, and that URL should expire quickly. Webhooks that report upload and processing results should be signed, for example with HMAC SHA-256, and your endpoint should verify the signature before trusting the payload.
Set the playback policy at creation. A recording from a KYC session, a telehealth visit or a proctored exam should be created private, with playback only through signed, expiring tokens, so it is never public even briefly. Some recordings also carry rules on location. In India, the RBI KYC direction requires recordings of V-CIP (video-based customer identification) sessions to be stored in systems located in India, with a date and time stamp. Where a rule like that applies, the storage location becomes a selection criterion for the upload API itself, not an afterthought.
What are common video upload API problems?
Most upload failures are network failures. A single-request upload loses all progress on a dropped connection, a client that retries too fast floods a weak link, and a mobile app that uploads only in the foreground stops when the user locks the phone. Chunked, resumable uploads with backoff and background transfer fix most of these.
The next group sits after the upload. Odd source files can fail transcoding even though the upload succeeded, so apps should handle the failure webhook, not only the success one. Apps that poll a status endpoint instead of listening for webhooks add load and delay. User-generated uploads also bring content risk. Platforms that accept public uploads usually run moderation on new assets before they are shown widely, and keep the publish decision in their own workflow.
How does FastPix handle video uploads?
FastPix offers two ways in. For files on a user's device, your backend asks the On-Demand API for a direct upload URL and hands it to the client. FastPix's resumable upload SDKs for web, iOS, Android and Flutter split large files into chunks and resume after a dropped connection, and accelerated, edge-routed uploads are built in and free. For files that already exist, FastPix pulls from S3, GCS, Azure Blob or any HTTPS URL, and the FastPix Migration Tool moves whole libraries from other video platforms or S3, with metadata mapping and status webhooks. The upload path is built for large files and long-form recordings.
Each asset gets a media ID for management and one or more playback IDs. Set a playback ID to signed and every view needs a JWT issued from your signing keys, with an expiry you choose. Webhooks fire on upload, encode and ready, including video.media.ready, and are signed with HMAC SHA-256. Just-in-time encoding lets playback start before the full encode finishes. In-Video AI can run alongside encoding to return a transcript with word-level timestamps and speaker diarization, plus moderation flags. Moderation returns flags only; the publish decision stays in your workflow. The live 1-to-1 call in a KYC or telehealth product is real-time calling, which FastPix does not run; its part is the recording, upload, storage, protection and transcription. For rules such as India's V-CIP direction on where recordings are kept, FastPix can set the storage region on request; ask FastPix which regions are available.
Accelerated uploads are free, and ingress is included in the per-minute streaming price rather than billed by the gigabyte. Encoding is counted per source minute and is free on Standard up to 4K; storage then bills per rendition-minute. The free plan accepts 10 videos, with no card.
