Bilibili Open Platform Video Submission Workflow and Upload Token Design

Author : Zhou Xin, Senior Development Engineer at Bilibili, joined in 2020 and has worked on CRM, asset, open, and MCN platforms, focusing on main site content services.

Platform Overview : Bilibili Open Platform provides basic services, industry solutions, and personalized services for media agencies, developer‑enabled creators, vertical enterprises, and brand service providers, aiming to co‑build a healthy content ecosystem.

Video Submission Process

Video submission consists of two main stages: video file upload and manuscript (稿件) submission.

Upload Pre‑processing : External applications call the pre‑processing API with client_id , access_token , name (full filename), and size . The service generates a 32‑bit UUID‑based filename , obtains a cid , constructs an upos_uri (bucket fixed as ugcboss ), and returns upload_id , upos_uri , cid , and filename .

Chunk Upload : Applications upload each chunk with client_id , access_token , upload_id , part_number (starting from 1), upos_uri (URL‑encoded), and the binary chunk data. The service stores the chunk temporarily in cloud storage.

Merge : After all chunks are uploaded, the merge API is called with client_id , access_token , upload_id , upos_uri , cid , and profile (fixed value ugcupos/openplat ). The service merges the chunks.

Manuscript Submission : The submission API receives client_id , access_token , video file info ( cid , filename ), and manuscript info (title, cover, tid, description, tags, etc.). After authentication, the service returns a manuscript ID.

Reflection : The version introduces a flexible authentication service to restrict operations within the user’s authorized scope, improving security. However, the large number of parameters increases integration difficulty.

Introducing upload_token

To reduce parameter complexity, an upload_token is generated after authentication and stored in Redis. It encapsulates internal parameters ( upload_id , upos_uri , cid , filename , etc.) and is passed to subsequent APIs.

Revised Workflow with upload_token

• Pre‑processing now only requires client_id , access_token , and name . The service returns an upload_token .

• Chunk upload uses upload_token , part_number , and the chunk binary. The service validates the token, retrieves the mapped parameters, and stores the chunk.

• Merge API receives only upload_token . The service validates the token and performs merging.

• Manuscript submission receives client_id , access_token , upload_token , and manuscript details. The service extracts video info from the token and completes the submission.

Providing a JS SDK

For front‑end integration, a JavaScript SDK is built on top of the upload_token scheme, allowing web clients to upload videos directly without exposing long‑lived access_token . The SDK handles token acquisition, file slicing, chunk uploading, progress reporting, and merge triggering.

Workflow steps include: selecting a local file, invoking the server‑side pre‑processing to obtain upload_token , using the SDK to slice the file, uploading each chunk, detecting completion, calling the merge API, and notifying the web client.

Benefits

The improvements reduced common parameter‑related errors (e.g., double URL‑encoding of upos_uri ), shortened the average time from qualification to first successful submission by 62.67%, and lowered the overall integration cost for third‑party platforms.

Future Evolution

Feedback is collected via public email, ticket system, log monitoring, and interface telemetry stored in Hive for BI analysis. Plans include expanding capabilities for small platforms, enhancing webhook failure notifications, and further consolidating APIs under a unified OpenAPI service.