Your YouTube API upload succeeded. The video still cannot be seen.
The call returns a video ID. The channel owner gets an email. And the video sits locked as private — because of a project-level rule that has nothing to do with your code.
This is one of the most confusing failures in the YouTube Data API, because nothing looks broken. There is no error code. The videos.insert request completes. The response contains a valid video resource. Your logs are clean.
Then the creator writes in and says the video is private and they cannot change it.
What the rule actually says
The restriction is published as a banner on YouTube’s own videos.insert reference page, and it is not a soft recommendation:
YouTube’s revision history for 28 July 2020 adds the part most teams never see, because the email goes to the creator and not to the developer:
So the person who finds out first is your customer. Not you.
The three things people get wrong
It is not a quota problem
Projects get 100 videos.insert calls per day by default, and the call costs 1 unit in its own bucket. Staying under quota does nothing to lift the private restriction — they are unrelated systems.
It is not a privacyStatus bug
You can set status.privacyStatus to public on the request. The project-level restriction overrides the outcome anyway. Changing your payload does not fix it.
The locked videos are not recoverable by appeal
YouTube’s Help Centre is explicit that videos locked this way cannot be appealed. Passing an audit later is not documented as un-privating anything already uploaded.
Read that carefully, because it changes the shape of the problem. Every day you run an unaudited upload pipeline, you are generating videos that your customers will have to re-upload manually. The cost is not the fix. The cost is the backlog you build before you notice.
Why the audit is heavier than a form
The route out is the YouTube API Services Audit and Quota Extension Form. It looks like a support request. It is closer to a business review. The form itself sets the expectation:
And the bar it is measured against is not a checklist you can tick off:
“Significant independent value” is the sentence that decides most outcomes, and it is the one nobody can answer with a screenshot. It is a positioning argument about your product, written for a reviewer who has never seen it. The form also collects your organisation and contact details, your business model, any existing Google relationships, and your use cases — each section an opportunity to contradict yourself.
What the process looks like from the outside
Establish which projects are actually affected
The rule keys off the API project and its creation date, not your channel or your app name. Teams with several Cloud projects, an old one and a new one, or an agency project inherited from a client, often audit the wrong one.
Bring the client into policy alignment before submitting
The Developer Policies impose concrete product requirements — for example, an upload client must clearly display an option for the user to choose public, private or unlisted, and the API Terms require a specific certification warning on the upload screen. Submitting before these exist invites a compliance finding.
Write the use case and the independent-value argument
This is the part that carries the decision. It has to describe real end-user value, match what a reviewer sees when they open your product, and stay consistent with your business model answers.
Give the reviewer working access
The Developer Policies require you to provide, on request and within the stated timeframe, accounts that reach all features of the current in-production version of your client. A demo environment that is not the production build is a problem, not a convenience.
Plan for the re-audit, not just the first one
YouTube states it conducts periodic audits, and there is a separate Periodic Audit Form. Approval is a state you have to keep, not a badge you collect.
The numbers that actually apply
Note what is missing from that list: a turnaround time. YouTube does not publish one. The only commitment in the documentation is that “a member of YouTube’s API Services team will contact you as soon as possible.” Anyone quoting you a specific number of days for a YouTube audit decision is quoting something YouTube has never published.
Where these submissions go wrong
- Auditing the wrong Cloud project, so the pipeline keeps producing locked videos after “approval”.
- Treating the upload restriction and the quota extension as the same request, and writing a use case that only argues for more quota.
- Missing the mandatory upload-screen elements — the privacy-status choice and the certification warning — that the Policies and Terms require of any upload client.
- A use case description that describes the API integration rather than the end-user value, which is what “significant independent value” is asking about.
- Reviewer access that does not reach the in-production build, so the client cannot be assessed.
- Assuming a failed outcome is final. A failed audit has an Appeals Form; individual locked videos do not. People frequently confuse the two and give up on the wrong one.
What we do on these
This is project-level compliance work, not a coding fix. It means identifying the affected project, closing the policy gaps in the client before anything is submitted, and building the use case and independent-value argument so the reviewer is reading a coherent case rather than assembling one. We do the same preparation work on YouTube Data API quota increase audits, on the API key versus OAuth 2.0 decision that triggers Google verification, and across Google OAuth sensitive and restricted scope review.
If your uploads are landing private, or you are about to build an upload pipeline and want the project audited before it starts generating locked videos, that preparation is what our API approval support services cover.