Your integration works. videos.insert returns a video ID, the file lands on the channel, and the feature ships. Then you request quota above the default allocation, and the YouTube audit form asks you to attach upload interface screenshots.

That is the moment most teams discover that the upload screen itself is a policy artifact. It has to show four things that Google’s terms require, and no amount of clean backend code substitutes for them.

The upload screen is evidence, not a promise

YouTube’s Audit and Quota Extension Form does not ask what your product intends to do. It asks for screenshots of the interface as it exists, plus demo account credentials with full access to every feature. Conditional evidence on the form is explicit: upload interface screenshots are requested when the declared use case is video uploading and account management.

The practical consequence is sequencing. If the required elements are missing when you submit, you are not fixing a form field — you are changing product UI, shipping it, re-capturing the evidence, and going back into the queue. Projects that enable the YouTube Data API start with a default allocation that includes a small daily videos.insert ceiling, which is exactly why an upload product has to reach the audit at all. The wider mechanics of that request are covered in our YouTube Data API quota increase and audit guide.

Four obligations that must be visible on the upload screen

Required Minimum Functionality

A real privacy selector

The RMF is unambiguous: the user — not your code, not a config default — must be able to choose whether the uploaded video is public, private or unlisted. A hardcoded value, or a setting buried in an account preferences page, does not satisfy it.

API ToS §9.1(i)

The certification warning

A specific warning must appear in the screen or window where the end user clicks upload — not on your terms page, not in a help article — and in the languages your client offers.

API ToS §9.1(ii)

The own-channel option

Users must be offered the option to upload to their own YouTube channel. If your product also uploads to your channel, that is allowed, but it carries a licence-notice duty and a prominence rule.

API ToS §9.1(iv)

Made for Kids handling

A client that is not child-directed must either let users designate content as Made for Kids before upload, or notify users inside the client that they need to declare it on YouTube desktop.

What the certification notice actually says

This one is quoted rather than paraphrased because the wording is prescribed. Section 9.1 of the YouTube API Services Terms of Service requires that the screen or window in which the end user clicks the upload button display the following warning, in the languages available on your client:

“By clicking ‘upload,’ you certify that the content you are uploading complies with the YouTube Terms of Service (including the YouTube Community Guidelines) at [select and insert appropriate URL from following paragraph]. Please be sure not to violate others’ copyright or privacy rights.”YouTube API Services Terms of Service, Section 9.1 (Americas version, last updated 28 April 2026). The terms specify a desktop URL and a separate mobile URL, and regional APAC, EMEA and Russia versions of the terms exist.

Two details trip people up. The URL is device-dependent, so a single responsive component that hardcodes one of them is not compliant across both contexts. And the notice belongs on the upload screen itself, which means it has to survive whatever redesign, modal flow or wizard your product uses.

The own-channel rule is a business decision, not a code change

Many products are built to collect user content into a company-owned channel. The terms permit it, but conditionally. Section 9.1(ii) requires that clients enabling uploads offer each user the option to upload to the user’s own channel. Where you also offer upload to your own channel, you must give clear notice of the licence terms attached to those videos — including that you will own or hold rights to them — and the option to upload to the user’s channel must be featured at least as prominently as the option to upload to yours.

Prominence is a design and product question that reviewers assess from your screenshots. It is where an otherwise compliant build most often needs rework, because the entire funnel was designed around the company channel.

The field rules that quietly constrain your form

The RMF also governs the metadata fields on the upload form. Title and description are required user-settable fields, and the developer policies go further: a client must not place limitations on functionality the RMF requires. Google’s own worked example is the title field — YouTube allows up to 100 characters, and a client must not impose a shorter maximum. There is a matching feature-parity rule for multi-platform tools: if you support a capability for other platforms, you generally have to support it for YouTube too, and users must be able to select and deselect the platforms they are uploading to.

These are the rules that make a “simplified” upload form into a compliance problem. Trimming fields for UX reasons is exactly the behaviour the policy prohibits.

What the work actually looks like

1

Map every obligation to a visible element

Each requirement has to correspond to something a reviewer can see in a screenshot. Obligations satisfied only in backend logic do not count as evidence.

2

Resolve the device and language variants

The notice text is fixed but its URL and its localisation are not. Every surface your client runs on needs the correct variant.

3

Settle the channel-ownership model

Own-channel versus company-channel affects your licence terms, your onboarding copy and your layout hierarchy. It is decided before the UI is finalised, not after.

4

Choose and build the Made for Kids path

Two permitted approaches exist and they have different product costs. Picking the wrong one late means reworking the upload flow.

5

Assemble the evidence set

Screenshots in accepted formats, a privacy policy that meets the specific YouTube clauses, a homepage capture, and a working demo account with sample data and full feature access.

What a properly built upload flow gets you

  • You submit with evidence rather than descriptions, which removes the most common source of follow-up rounds.
  • No mid-review rebuild — the interface reviewers see is the interface that is already live.
  • Your privacy policy, terms and upload UI tell one consistent story instead of contradicting each other.
  • Periodic re-audits and use-case changes become routine rather than a fresh emergency.

Where these submissions go wrong

  • Privacy status set silently in code, with no user-facing choice at upload time.
  • The certification warning placed on a terms page or a footer instead of the upload screen.
  • One hardcoded terms URL used for both desktop and mobile contexts.
  • Company-channel upload presented as the primary path, with the user’s own channel demoted or absent.
  • No Made for Kids designation and no in-client notice pointing users to YouTube desktop.
  • Title or description fields capped shorter than YouTube’s own limits for UX tidiness.
  • A privacy policy that never names YouTube API Services, omits the Google Privacy Policy link, or lacks the revocation and deletion language.
  • A demo account supplied without full feature access or sample data, so reviewers cannot reach the upload flow at all.

Getting this right before you submit

The pattern across these projects is the same: the engineering was never the bottleneck. The obligations sit at the intersection of product design, legal copy and platform policy, which is exactly the seam where in-house teams have no clear owner. Reviewing an upload flow against the current terms before submission — rather than after a rejection — is where the time is actually saved.

If your uploads are landing private, or you are already inside an audit cycle, that is a related but separate problem. It is also worth confirming which credential model your project uses, since that determines whether Google OAuth verification applies on top of the YouTube audit — see YouTube API key vs OAuth 2.0. A full overview of what we handle is on the services page.

This article summarises publicly available YouTube and Google developer documentation as of August 2026, including the YouTube API Services Terms of Service, the Developer Policies, the Required Minimum Functionality specification and the Audit and Quota Extension Form. Platform terms change; always verify against the current official documentation before building. Review outcomes depend on your application, your data handling and Google’s assessment, and no specific outcome or timeline can be guaranteed. This site is independent and is not affiliated with, endorsed by or sponsored by YouTube, Google or Alphabet.