Resumable upload protocol for video APIs

A protocol can split a file into chunks without being resumable — if the server has no way to report which chunks it already has, a client that loses its session has to start the whole sequence over regardless of how many chunks succeeded first. Resumability adds a query step: at any point, the client can ask the server for its current progress and get back an authoritative answer, instead of tracking progress locally and hoping its own record matches reality after a crash or a lost connection.

YouTube's resumable upload protocol is the clearest documented example of the pattern. Initiate a session: send the file's metadata and declare its size and MIME type up front; the server responds with a session URI dedicated to that one upload. Transfer in byte ranges: PUT the file's bytes to that session URI, one or more times, each request declaring exactly which byte range it covers via a Content-Range header. Query and resume: if a transfer is interrupted, send an empty-body PUT with Content-Range: bytes */TOTAL — the server replies with exactly which bytes it has already received, so the client resumes from that offset instead of guessing. The full mechanics, including the 308 Resume Incomplete response and the 256 KiB chunk-size alignment YouTube requires, are covered in YouTube's resumable upload protocol, step by step.

The vocabulary differs, but the underlying pattern — declare size and type up front, transfer in verifiable pieces, ask the server for authoritative progress — recurs across unrelated protocols. The open tus resumable upload protocol formalizes it as a vendor-neutral HTTP spec with its own Upload-Offset header doing the same job as YouTube's Content-Range query. Amazon S3's multipart upload achieves the same resilience with numbered, independently-retryable parts and their ETags instead of a continuous byte-range session. LinkedIn's own video upload API follows a comparable initialize-then-upload-parts shape as well — see LinkedIn Video Upload API for how that one is structured. Different vocabulary, same underlying goal: never make a client re-send a byte the server already has.

Video files are large, and the situations that produce them — a phone on a spotty cellular connection, a marketing team member on a hotel network — are exactly the situations where a connection is most likely to drop mid-transfer. Without resumability, a drop 95% of the way through a 40-minute upload means starting the entire 40 minutes over. With it, the client loses only the time since its last acknowledged byte. That difference is why platforms with any meaningful video upload volume require the resumable protocol rather than accepting a plain single-shot POST for anything beyond a small test file.

PostGate's media pipeline carries out the resumable relationship with the destination platform on your behalf. Pre-upload a file — directly or via multipart upload for large assets — to POST /api/media, and PostGate manages sessions, byte-range or part-based transfer, and progress tracking against the actual platform internally before your post request ever runs. Your integration deals with a single media ID; PostGate deals with session URIs, part uploads, and Content-Range headers wherever the destination platform requires them.