Uploading YouTube Shorts by API: There Is No Shorts Endpoint

What videos.insert actually lets you set

Google publishes the full list of properties a client may set on upload. It is short, and it is worth reading closely for what is missing:

The upload endpoint itself is a plain media upload to POST https://www.googleapis.com/upload/youtube/v3/videos, accepting video/* or application/octet-stream, with a maximum file size of 256GB. It requires one of four OAuth scopes — youtube.upload, youtube, youtubepartner, or youtube.force-ssl. None of those scopes changes anything about Shorts.

So who decides it is a Short?

YouTube does, from the properties of the video file, after it has been received. Google’s own creator documentation sets it out as a dated rule rather than an API feature:

Google states the only lever a creator has in the other direction: if you do not want content classified as a Short, use a wider aspect ratio such as 16:9. That is an instruction about the video file, not about an API field — which is precisely the point. Your integration controls the outcome only through the media it encodes and uploads, never through the request body.

Three gates that compound on top of it

1. The upload quota is a hard daily count, not a unit budget

The Data API used to pool everything into one 10,000-unit daily allowance. That is no longer how uploads are metered. Google’s current quota table puts videos.insert in its own bucket with a default limit of 100 calls per day, each costing 1 quota — and search.list in a separate bucket on the same terms. Everything else shares the 10,000-unit pool. Quotas reset at midnight Pacific Time.

This matters for a scheduler in a very concrete way. A hundred uploads per day across your entire project, not per connected channel, is a low ceiling for any multi-tenant tool. It is also worth knowing that the older figure still circulating in tutorials — a 1600-unit cost per upload — is not what the current published table says. Building a capacity model on the stale number produces the wrong answer in both directions.

2. Unverified projects upload straight into private

Google states it at the top of the videos.insert reference: every video uploaded from an unverified API project created after 28 July 2020 is restricted to private viewing mode. The call succeeds. The video ID comes back. Nobody can see it. Lifting the restriction requires an audit of the project against the API Terms of Service. A vertical clip that nobody can watch is not a Short in any sense that matters commercially.

3. Over a minute, one copyright claim blocks the Short globally

This is the trap that catches tools built for music-adjacent content. Per Google’s three-minute Shorts documentation: any Short over one minute in duration with an active copyright claim of any type, including manual claims, will be blocked globally on YouTube — not playable, not recommended, not eligible for monetisation. There is no channel penalty, and the block lifts once the claim is resolved, but the video is dark until then. Shorts under one minute are explicitly unaffected. For soundtrack use, Google notes most Shorts Audio Library songs are usable for up to 90 seconds inside a three-minute Short, with some tracks capped at 60 or 30 seconds.

Where builds actually stall

• The upload works and the video is invisible. Almost always the unverified-project rule, not a bug in your code — and the fix is an audit, not a retry.
• Vertical clips land as long-form. The encoder is emitting a padded 16:9 frame, or the duration crossed the window. The API will never tell you; you find out by looking at the channel.
• The daily ceiling is hit at ten channels, not a hundred. The 100-upload bucket is per project. Multi-tenant capacity planning has to start there, and raising it means passing a compliance review.
• Shorts go dark after publishing. Over-one-minute Shorts with any claim on them are blocked worldwide, which reads to a customer like the tool broke.
• The audit request gets rejected on the client UI, not the code. Google reviews what the upload interface shows the user, and that is assessed separately from whether the integration works.

What this looks like as a piece of work

1. Establish what the project is actually permitted to doVerification state, scope set, current quota bucket position, and whether previous uploads are sitting private.
2. Reconcile the media pipeline against the classification windowAspect ratio and duration as they exist in the uploaded file, not as they exist in the source asset.
3. Prepare the audit submissionClient interface, policy compliance, and data handling assessed against YouTube’s Developer Policies before anything is sent.
4. Design the capacity and failure modelDaily bucket limits, private-lock detection, claim-block handling, and what the end user is told when YouTube’s decision differs from their intent.

This is submission and implementation support work: reading the current policy correctly, getting the project into a state that passes review, and making the product honest about what the API can and cannot promise. It is not a settings change, and no specific review outcome can be promised by anyone — YouTube alone decides.

Verified against Google’s published documentation on 8 August 2026: the YouTube Data API videos.insert reference, the Data API quota cost table, and YouTube Help’s three-minute Shorts guidance. Platform rules change frequently — always confirm against the current official pages before relying on any figure here. This site is independent and is not affiliated with, endorsed by, or partnered with YouTube or Google.

Related reading on this site: the private-upload rule is covered in detail in YouTube API Uploads Locked as Private; the interface obligations Google reviews are set out in YouTube Upload Client Requirements; and the process for raising limits is covered in YouTube Data API Quota Increase: How the Audit & Compliance Review Works.