YouTube Data API

YouTube Comments API Moderation: The OAuth Scope Behind setModerationStatus (2026)

Approving, holding, or rejecting a YouTube comment through the API is not a simple status flip. It needs channel or video ownership, the same OAuth scope YouTube uses for its most sensitive write actions, and a quota budget that adds up fast on an active channel.

The catch: setModerationStatus only accepts three target values — heldForReview, published, rejected. A fourth status, likelySpam, exists on every comment resource but cannot be set through this method at all. It is assigned by YouTube's own spam detection, not by your app.

Four separate methods, one moderation workflow

commentThreads.insert

OAuth required

Creates a new top-level comment on a video. Requires snippet.channelId, snippet.videoId, and snippet.topLevelComment.snippet.textOriginal.

comments.insert

OAuth required

Creates a reply to an existing comment. Requires snippet.textOriginal and snippet.parentId — a top-level comment cannot be created here.

comments.list

1 quota unit

Retrieves comments by id or parentId. The lightest call in the set, and the only one that does not require write authorization.

comments.setModerationStatus

OAuth required

Sets heldForReview, published, or rejected on one or more comment IDs, with an optional banAuthor flag. No request body — everything is a query parameter.

Where the moderation workflow adds real complexity

Ownership-gated, not user-gated

Google's documentation is explicit: the setModerationStatus request must be authorized by the owner of the channel or the video the comments belong to — not just any authenticated viewer.

One scope covers the whole write surface

Every write method here — insert, update, delete, setModerationStatus — sits behind a single documented scope: youtube.force-ssl. There is no narrower, moderation-only scope to request.

banAuthor has one valid condition

The banAuthor parameter only works when moderationStatus is set to rejected. Send it with heldForReview or published and the API returns a banWithoutReject 400 error.

A legacy error still ships

The documented operationNotSupported error reads: “Comments not based on Google+ offer only limited moderation functionality” — a Google+-era limitation that can still surface on older comment threads.

Inserting needs a merged account

commentThreads.insert and comments.insert both document an ineligibleAccount error: the authorizing YouTube account must be merged with a Google Account before either call succeeds.

Quota adds up on an active channel

setModerationStatus and both insert methods each cost 50 quota units per call. A queue that moderates hundreds of comments a day burns through the default daily allocation quickly.

The build path, at a high level

  • 1

    Map which of the four methods the feature actually needs — reading, posting, replying, and moderating are four different authorization and quota decisions, not one.

  • 2

    Configure the OAuth consent screen and request the youtube.force-ssl scope, since it covers every write action in this workflow.

  • 3

    Confirm the account calling setModerationStatus is authenticated as the channel or video owner — a shared or delegated login will not pass this check.

  • 4

    Design the moderation queue around the three settable states, and handle likelySpam as a read-only signal rather than something your app can assign.

  • 5

    Build error handling for the documented 400/403/404 responses — banWithoutReject, forbidden, commentNotFound, and the legacy operationNotSupported case — before the queue goes live.

What the documentation actually confirms

1OAuth scope covers every write method (youtube.force-ssl)
3 of 4moderation states an app can actually set
50quota units per setModerationStatus, insert, or reply call

Documented error responses to plan around

ErrorWhere it applies
banWithoutReject (400)banAuthor sent without moderationStatus=rejected
operationNotSupported (400)Legacy Google+-era comments with limited moderation support
processingFailure (400)Malformed or invalid request, on setModerationStatus and both insert calls
forbidden (403)Caller is not the authorized channel/video owner
ineligibleAccount (403)Insert calls only — account not merged with a Google Account
commentNotFound (404)One or more comment IDs in setModerationStatus don't exist
Deliberately excluded as unverifiable: Google's public documentation does not publish a sensitivity classification for the youtube.force-ssl scope on a per-endpoint basis, a moderation-queue UI specification, or any rate limit beyond the standard quota system. Those points are left out here rather than guessed at. The markAsSpam method referenced in some older tutorials and client libraries is also no longer supported — current documentation only lists list, insert, update, delete, and setModerationStatus for comments.

Getting a comment moderation feature past Google's OAuth verification — and keeping it inside quota — is a scope, ownership, and error-handling problem before it is a coding problem. See related coverage on YouTube API key vs OAuth 2.0, the YouTube Data API quota increase audit process, and the YouTube API Approval Service for hands-on setup support.