Facebook Video Upload API: Resumable Upload Explained (2026)

Meta's own developer documentation currently describes two different ways to get a video onto a Facebook Page — and one of them runs on a host Meta calls deprecated in another part of the same documentation set. A scheduler that mixes the two gets confusing, hard-to-diagnose errors.

Two documented flows, one goal

Flow A — Resumable Upload API

The current, general-purpose path. You start an upload session against your app (not the Page), stream the file to a session endpoint, then hand the resulting file handle to the video publish call. Runs entirely on graph.facebook.com.

Flow B — Page-video upload_phase flow

An older, video-specific tutorial flow that still appears in Meta's own Get Started guide. It talks directly to the Page endpoint using start / transfer / finish phases and manually tracked byte offsets — on a host Meta's own upload guide says is deprecated.

Official contradiction, not resolved

Meta's Resumable Upload API guide states the graph-video.facebook.com host for video uploads has been deprecated and that graph.facebook.com should be used instead. The Video API's own Get Started tutorial, live on developers.facebook.com today, still walks through the exact same upload_phase flow against graph-video.facebook.com. Both pages are current. We flag this rather than pick a side — and it is exactly the kind of gap that gets a scheduler's video posting feature built against the wrong host.

Where the two flows actually diverge

Who holds the token

Flow A starts the upload session against your App ID using a user access token, then publishes with a separate Page access token from someone holding the CREATE_CONTENT task. Flow B uses the Page access token from the very first request. Reuse the wrong token at the wrong step and the session simply fails to open.

What you get back

Flow A hands you an opaque file handle string to attach to the publish call. Flow B hands you an upload_session_id plus numeric start_offset / end_offset values you must track and increment yourself between chunk uploads. The two response shapes are not interchangeable.

How resumption works

Flow A lets you query the session at any time to recover the exact byte offset to resume from after an interruption. Flow B expects your own chunking logic to already know which chunk comes next — there is no equivalent recovery call in the tutorial flow.

What "success" actually means

Both flows return a success response once the upload finishes, before Meta has finished encoding the video. A scheduler that treats that response as "the video is live on the Page" instead of "the video is now processing" will show a false-positive posted status to end users.

What this looks like in practice

2documented upload flows for the same goal
3different Meta video-upload hosts across current docs
1host both marked deprecated and still documented live

Common failure points we see in scheduler builds

  • Host/parameter mismatch: sending Flow B's upload_phase parameters to Flow A's endpoint (or the reverse), which the Graph API rejects rather than silently correcting.
  • Token-level mismatch: opening the upload session with a Page token instead of a user token where the flow expects one, or publishing with a user token where a Page token with the CREATE_CONTENT task is required.
  • Offset drift: resuming a Flow B upload from a locally-tracked offset that no longer matches what Meta's servers actually received, corrupting the reassembled file.
  • Premature "posted" status: marking a scheduled post complete the moment the upload call returns success, before Meta's encoding step finishes.
  • CREATE_CONTENT gap: the Page access token was generated by someone who does not currently hold the CREATE_CONTENT task on that Page, which fails the publish step even though the upload itself succeeded.

Building a Facebook or Instagram video-posting feature into a scheduler, CRM, or SaaS tool means choosing the right flow, handling the right token at each step, and telling real completion apart from a queued encode — on top of the app review process required before pages_manage_posts and pages_read_engagement are even granted. Related reading: how Facebook Business Extension triggers its own separate review, and the Facebook App Review service page for how this fits into a full submission.

Information verified against Meta's official developers.facebook.com documentation as of August 2026. Meta's app review and platform policies change; always confirm current requirements directly with Meta before submission. No specific approval outcome can be guaranteed.