videos.insert OAuth scope: youtube.upload or force-ssl?

For a pipeline that only uploads Shorts, ask for the upload scope that videos.insert lists. The method's page says the request needs authorization with one of four scopes: youtube.upload, youtube, youtubepartner or youtube.force-ssl. Pick the narrowest one that does the job; the pages I read do not describe what each scope grants beyond its name, so confirm the grant on the consent screen before you ship.

Separately, YouTube's API revision history records that on September 1, 2026 the videos.getRating method started accepting the https://www.googleapis.com/auth/youtube.readonly scope. Both facts were read on 2026-10-03 from the videos.insert page and the revision history. Sume does not call YouTube, so these scopes belong to your own app.

Which scopes does each method accept?

The two methods in question accept different sets, and the revision-history entry shows the lists change over time, so read the method page for the call you are making rather than copying a scope from an old tutorial.

Why not request the broadest scope?

A broader scope means a broader consent screen and a bigger loss if a token leaks. A scheduled uploader that sits on a server holds a refresh token for months, so give it the least it needs. The pages I read do not rank the scopes for you, which is why this post stops short of naming a winner beyond the narrowest-that-works rule.

The scope is only half of the gate. Videos from an unverified API project created after July 28, 2020 are restricted to private mode until the project undergoes an audit, per the insert page, so a perfect scope still produces private uploads on an unaudited project. Which audit form to file and the private batch note cover that.

How do the YouTube and Sume credentials differ?

They never mix. YouTube asks for an OAuth 2.0 access token tied to a Google account, sent with the scope above. Sume takes a workspace API key as a Bearer token on api.sume.com, and jobs belong to the member whose key created them, as described in Jobs and results. A worker that does both should keep the two secrets in separate variables and log neither.

# Sume: render or trim a clip (workspace API key)
curl -X POST https://api.sume.com/v1/video-trim \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Idempotency-Key: trim-ep1" \
  -H "Content-Type: application/json" \
  -d '{"video_url":"https://media.sume.com/artifacts/artf_demo/talk.mp4","start":0,"duration":58}'

# YouTube: start a resumable upload session (Google OAuth token, scope youtube.upload)
curl -X POST "https://www.googleapis.com/upload/youtube/v3/videos?part=snippet,status&uploadType=resumable" \
  -H "Authorization: Bearer $GOOGLE_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"snippet":{"title":"Ep 1"},"status":{"privacyStatus":"private"}}'

What should I read stats with?

If you only read, the youtube.readonly entry shows YouTube widening what a read-only token can do for one method. For a count of the Shorts you made, batchGetStats at one quota unit is the better fit, and the quota side lives in the Video Uploads bucket note.

What should I log and store?

Store the refresh token encrypted, store the scope it was granted with next to it, and log the scope on every upload. When a call fails with an authorization error, the first question is whether the token carries the scope the method needs, and a logged scope answers it in one line.

Do not log the token, and do not put it in a job payload you send to Sume. A Sume job takes media URLs and render settings; it has no field for a Google token, and none should ever travel in a webhook callback either. Rotate the Sume key and the Google credential on their own schedules.

If your pipeline later adds a read step, such as checking ratings, request the extra scope in a separate consent rather than widening the upload token. The September 1 revision-history entry makes that easier for videos.getRating, because a read-only scope now fits that method.