YouTube API Upload Private: Your Script Worked. The Audit Is Why Nobody Can See It.
- Google’s docs: "All videos uploaded via the videos.insert endpoint from unverified API projects created after 28 July 2020 will be restricted to private viewing mode." Fetched 19 Sep 2026.
- The fix is not in your code. "To lift this restriction, each API project must undergo an audit to verify compliance with the Terms of Service."
- Three questions tell you in under a minute whether this is your problem: project creation date, audit status, and whether the video reads back as private.
- TikTok applies the same design to its Content Posting API — unaudited clients post private only. Unaudited means invisible on both platforms.
Your script ran clean. A video ID came back. The upload showed up in YouTube Studio with the right title, the right thumbnail, the right tags. Three days later it has zero views, and it is not a reach problem — you open it and the visibility dropdown says Private, and changing it does not stick.
You did not make a mistake in your request body. You ran into a gate that has been in place since 2020 and is documented in one sentence that almost nobody reads before they start building.
The sentence, and where it lives
We fetched Google’s YouTube Data API reference for videos.insert on 19 September 2026. It states:
"All videos uploaded via the videos.insert endpoint from unverified API projects created after 28 July 2020 will be restricted to private viewing mode."
And immediately after, the remedy:
"To lift this restriction, each API project must undergo an audit to verify compliance with the Terms of Service."
The API revision history, fetched the same day, dates the change to 28 July 2020. So this is not new, not a bug, and not something a library version will fix. It is a deliberate gate placed between "your code works" and "your uploads are visible", and it is placed at the level of the API project, not the account, not the channel, and not the video.
That last distinction is where most of the wasted debugging happens. People assume a visibility problem belongs to the video, so they re-upload with a different privacy status. Then they assume it belongs to the channel, so they check monetisation, strikes and age restrictions. The restriction is attached to the Google Cloud project holding the API credentials. Nothing you change on the YouTube side moves it.
The most expensive bugs are the ones where every layer reports success. This is one: correct request, valid response, real video ID, invisible video.
Three questions that settle it in under a minute
Before you touch any code, answer these in order. The first two are the diagnosis; the third is the confirmation.
- When was the Google Cloud project created? Not your account, not your channel — the project that owns the OAuth client your script authenticates with. Google’s wording covers projects created after 28 July 2020. If yours was created any time in recent years, it is in scope.
- Has that project been through the compliance audit? If you cannot remember submitting one, you have not. The audit is an explicit application, not something that happens automatically because your integration works.
- Read the privacy status back from the API. Do not check it in Studio, where you may be looking at a cached view or misreading a processing state. Fetch the video resource and read its privacy status field. If you requested public and it reads back private, you have your answer and it is not ambiguous.
A practical note on that third step: the documentation describes the restriction as applying to videos uploaded from unverified projects, and it does not carve out an exception for the privacy status you asked for. So requesting public and getting private is the expected behaviour here, not a symptom of a malformed request. Reading the value back is simply the cheapest way to prove which of the two worlds you are in before you spend an afternoon rewriting your upload code.
One more thing worth knowing while you are in there: the same reference page states that a call to this method has a quota cost of 1 unit in the Video Uploads quota bucket. The uploads bucket is separate from the general quota, which is why "I have plenty of quota left" and "my uploads stopped" are not contradictory statements.
Unaudited means crippled, in the same way, on two platforms
Here is the part that turns this from a YouTube annoyance into a useful piece of category knowledge.
We also fetched TikTok’s Content Posting API documentation on 19 September 2026. It says: "All content posted by unaudited clients will be restricted to private viewing mode," and lifting that requires an audit to verify compliance with TikTok’s terms. Its content sharing guidelines add a second ceiling on the same clients — "Unaudited API Clients can allow up to 5 users to post in a 24 hour window."
Two of the largest video platforms, independently, landed on the same design: an unaudited integration may prove it works and may not be seen. Once you notice the pattern, a whole class of forum question resolves itself.
| YouTube Data API | TikTok Content Posting API | |
|---|---|---|
| What an unaudited client can do | Upload successfully | Post successfully |
| What the audience sees | Nothing — restricted to private viewing mode | Nothing — restricted to private viewing mode |
| Extra ceiling | Uploads quota bucket, 1 unit per call | Up to 5 users posting per 24 hours |
| How it lifts | Project audit against the Terms of Service | Client audit against the Terms of Service |
The strategic reading: on both platforms, the official API is a product surface for public applications, not a private back door for your own roster. TikTok says so explicitly in its Intended Use section, which we pulled apart in what TikTok’s API says about posting to accounts you manage. YouTube says it with the audit instead of with prose, but the effect on a solo builder is identical.
What to do while the gate is closed
You have three real options, and they are not equally good for everyone.
- Apply for the audit. Correct if you are building an actual product for other people. Budget calendar time, not engineering time — approval queues are the part nobody schedules, and one vendor finally published a figure on that in how long social media app approval takes.
- Upload the normal way. If your channels are your own and the only reason you reached for the API was convenience, the browser upload flow has no audit gate, because it is not an API client. It is you, signed in, uploading. Everything you were trying to automate around it — drafting, thumbnails, descriptions, scheduling — can still be automated; the publish step just happens where YouTube expects it to. The queue mechanics are in bulk uploading to YouTube.
- Stop using someone else’s audited project. If a third-party tool is uploading on your behalf, your videos are going out through their audited project and under their quota. That is fine right up until their quota or their audit becomes your outage.
The second option is the one most solo operators actually want, and it is the architecture our own desktop app is built on: NoobClaw opens a local browser, you sign in to your own channels yourself, and nothing about a password ever leaves your machine. Each channel in a matrix generates its own material from its own niche and persona rather than one file being pushed across all of them. Keep a human review step before anything publishes — the audit gate is not the only reason uploads go wrong, and an unreviewed pipeline produces the exact near-duplicate pattern that causes the next problem. If you are assembling this stack yourself, the honest accounting of what automation removes and what it only relocates is in faceless YouTube automation with n8n, and the boundaries YouTube draws around automated operation are in what you can automate on Shorts.
FAQ
Why is my YouTube API upload private when I set privacyStatus to public?
Because the restriction is applied at the API project level, not per request. Google’s documentation states that all videos uploaded via videos.insert from unverified API projects created after 28 July 2020 will be restricted to private viewing mode, and it does not exempt a requested privacy status. Confirm it by fetching the video resource back and reading its privacy status — if you asked for public and it reads private, the project is the cause.
Can I just change the video to public in YouTube Studio afterwards?
The documentation frames the restriction as a property of uploads from unverified projects and points to one remedy: an audit of the API project. We are not going to promise you a manual workaround the docs do not describe. If you need public uploads and do not want to run an audit, the reliable route is to upload through the normal signed-in flow rather than through the API.
Does this affect API projects created before 28 July 2020?
Google’s wording is specific to projects created after 28 July 2020, and the revision history dates the change to that day. Older projects are described differently, with developers encouraged to complete a compliance audit rather than being restricted outright. If you are inheriting an old project, check its audit status rather than assuming its age exempts it.
