videos.insert embeddable and publicStatsViewable for a Shorts batch

status.embeddable and status.publicStatsViewable are settable on videos.insert. Set both explicitly in a Shorts batch body and check them with a small script.

5 min readSume
All posts

Set both fields in every request. status.embeddable says whether the video can be embedded on another website, and status.publicStatsViewable says whether the extended statistics on the watch page are publicly viewable. Both are listed as settable on videos.insert, so a Shorts batch can pin them instead of leaving them to whatever the platform does when the field is absent.

The definitions below come from the YouTube Data API Videos resource and the videos.insert page, read on 2026-10-03. Neither page states a default for either field in the sections I read, so this post does not assume one.

What do the two fields mean?

The Videos resource defines status.embeddable as indicating whether the video can be embedded on another website, and status.publicStatsViewable as indicating whether the extended video statistics on the watch page are publicly viewable. Both sit in the status object, which also holds privacyStatus, license, publishAt, selfDeclaredMadeForKids and containsSyntheticMedia.

Two things the pages do not say are worth stating plainly. They do not tell you what a Short's watch page shows, and they do not say what the embed does on a site that only shows horizontal players. If you plan to embed a vertical Short on your own site, test one upload before you queue a batch.

Status fields settable on videos.insert (read 2026-10-03)
FieldWhat the page says it does
status.embeddableWhether the video can be embedded on another website
status.publicStatsViewableWhether extended statistics on the watch page are public
status.privacyStatusSet on insert; unverified API projects are limited to private
status.publishAtScheduled publish time; only when the video is private

How do I keep a batch consistent?

A batch is where defaults hurt: one row forgets a field and the whole season is inconsistent. Put the status block in one constant and merge each row's title and description into it. The script below fills the block, checks that the two booleans are real booleans, and prints the JSON body for one row. It runs as-is with Python 3.

import json

STATUS = {
    "privacyStatus": "private",
    "embeddable": True,
    "publicStatsViewable": False,
    "selfDeclaredMadeForKids": False,
}

def body(title, description):
    for key in ("embeddable", "publicStatsViewable"):
        if not isinstance(STATUS.get(key), bool):
            raise ValueError(key + " must be set to true or false")
    return {
        "snippet": {"title": title, "description": description},
        "status": STATUS,
    }

print(json.dumps(body("Episode 2", "Part two of the season."), indent=2))

Where does Sume come in?

Sume produces the MP4s; the YouTube fields stay on your side. A video trim job takes one media.sume.com clip and returns a new MP4, and its default mode is async, so poll the job as described in Jobs and results before you upload anything.

Sume does not call videos.insert. Its docs describe no YouTube upload endpoint, so the batch loop, the OAuth consent and the quota bookkeeping are yours. The Video Uploads quota bucket is the limit that decides how many rows you can send in a day.

What should I check after the upload?

Open the first video of the batch in Studio and confirm both settings read the way your constant says, then let the rest run. If you are also setting the kids flag, the two made-for-kids fields behave differently on read and write. For a backfill where you do not want a notification per upload, see notifySubscribers on bulk uploads.

What are the risks of leaving them out?

The risk is inconsistency, not failure. If the API applies a default you did not choose, a whole season can go out with settings you never reviewed, and changing them later means one edit per video. Setting both fields in a shared constant turns a per-video decision into one reviewed line of code.

It also makes a change auditable. When someone asks why a season's statistics were public, the answer is in the constant and in version control, not in a platform default that may change. The revision history page is the place to watch for changes to the API; I read it on 2026-10-03 and its latest entries concerned file sizes, thumbnails, view counting and a comment image property, not these two fields.

Keep the constant per channel, not per run. If one channel wants embedding off and another wants it on, two constants beat a conditional inside the loop.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume