Skip to main content
By Marcel Czuryszkiewicz, Founder @ bundle.social Building & shipping social tools since 2024. Learning YouTube’s quirks so you don’t have to.

TL;DR

  • Shorts Aren’t Special (To the API): There’s no dedicated “Shorts” endpoint. You use the standard video upload API, and YouTube decides if your video qualifies as a Short.
  • Processing Delays Are Real: Your upload succeeds, but the video isn’t watchable for minutes. Plan for this in your UX.
  • Quota Will Hurt You: The default 10,000 daily quota sounds generous until you realize one upload costs 1,600 units. That’s 6 uploads per day.

The Shorts That Isn’t

Here’s the first thing that confuses developers approaching the YouTube Shorts API: there isn’t one. Not really. When you search for “YouTube Shorts API” hoping to find dedicated endpoints for uploading Shorts, setting Shorts-specific metadata, or pulling Shorts analytics, you’ll find yourself deep in the standard YouTube Data API v3 documentation with no clear Shorts section. That’s because, from an API perspective, Shorts are just videos with certain properties. YouTube determines whether an uploaded video becomes a Short based on these criteria:
  • Vertical or square aspect ratio (9:16 is ideal)
  • Duration under 3 minutes (180 seconds)
  • That’s essentially it
There’s no flag you set, no special endpoint you call, no Shorts-specific upload flow. You use the regular videos.insert endpoint, upload a short vertical video, and YouTube takes it from there.
This is documented, technically, but you have to piece it together from scattered references across multiple documentation pages. Many developers spend hours looking for the “Shorts” section before realizing they’ve been reading the right documentation all along - it just doesn’t say “Shorts” anywhere.
The practical implication: any code you’ve written for regular YouTube uploads works for Shorts with zero modification. Same endpoints, same authentication, same metadata structure. The only difference is the content you’re uploading.

The Processing Purgatory

Here’s something the documentation glosses over that will bite you in production: upload success does not mean playback readiness. When you upload a video via the API, the response comes back within seconds telling you the upload succeeded. You get a video ID. Everything looks great. Your UI shows a success message. Then your user tries to watch the video and sees… a processing screen. Or worse, an error. YouTube needs to process every uploaded video before it’s playable:
  • Transcoding to multiple resolutions
  • Generating thumbnails (unless you provided a custom one)
  • Running content analysis
  • Various other backend operations
For a 30-second Short, this typically takes 1-3 minutes. For longer content or during high-traffic periods, it can take significantly longer. The API gives you a way to check processing status through the videos.list endpoint with the processingDetails part. But here’s the gotcha: processingDetails isn’t always immediately available. Right after upload, this field might be missing entirely. You need to poll, and you need to handle cases where the data isn’t yet present.
const checkProcessingStatus = async (videoId, accessToken) => {
  const response = await fetch(
    `https://www.googleapis.com/youtube/v3/videos?id=${videoId}&part=processingDetails,status`,
    {
      headers: { 'Authorization': `Bearer ${accessToken}` }
    }
  );
  
  const data = await response.json();
  const video = data.items[0];
  
  // processingDetails might not exist yet
  if (!video.processingDetails) {
    return { status: 'processing', progress: 'unknown' };
  }
  
  return {
    status: video.processingDetails.processingStatus,
    progress: video.processingDetails.processingProgress
  };
};
In your application, you need to decide how to handle this gap:
  • Show a “processing” state in your UI and poll until the video is ready
  • Use push notifications (YouTube does have them, though they’re not well-documented for processing completion)
  • Simply inform users that videos take a few minutes to become watchable
Don’t assume the video is ready just because the upload succeeded. Your users will complain, and they’ll be right.

The Quota Nightmare

YouTube’s API quota system is, to put it charitably, not intuitive. And it will become the limiting factor of your application faster than you expect. Every API operation costs a certain number of quota units. You start with 10,000 units per day. Sounds like a lot, right? Here’s the reality:
OperationCostDaily Limit (10k quota)
Upload a video (videos.insert)1,600 units~6 uploads
Set custom thumbnail50 units200
List videos1 unit per result10,000
Read video metadata1 unit10,000
6 uploads per day. For a multi-channel scheduling application, that’s nothing. That’s barely enough for one active creator, let alone a platform serving multiple users. And the error you get when you exceed quota? A generic 403 with a quotaExceeded reason - no information about when the quota resets (midnight Pacific Time, btw) or how close you are to the limit. To actually build a production application, you need to apply for a quota increase through the Google Cloud Console. This involves filling out a form explaining your use case, providing usage estimates, and waiting for Google to review it. Expect anywhere from a few days to a few weeks. Plan for this delay before you promise users an upload feature. In the meantime, you need quota-aware code:
const QUOTA_COSTS = {
  'videos.insert': 1600,
  'videos.list': 1,
  'channels.list': 1,
  'thumbnails.set': 50
};

class QuotaTracker {
  constructor(dailyLimit = 10000) {
    this.dailyLimit = dailyLimit;
    this.used = 0;
    this.resetTime = this.getNextReset();
  }
  
  getNextReset() {
    // Quota resets at midnight Pacific
    const now = new Date();
    const pacific = new Date(
      now.toLocaleString('en-US', { timeZone: 'America/Los_Angeles' })
    );
    pacific.setHours(24, 0, 0, 0);
    return pacific;
  }
  
  canAfford(operation) {
    if (Date.now() > this.resetTime) {
      this.used = 0;
      this.resetTime = this.getNextReset();
    }
    return (this.used + QUOTA_COSTS[operation]) <= this.dailyLimit;
  }
  
  record(operation) {
    this.used += QUOTA_COSTS[operation];
  }
}

The Thumbnail Trap

Custom thumbnails for Shorts are a common source of confusion. You can set them, but the behavior isn’t what you’d expect. For regular YouTube videos, custom thumbnails are essential - they’re the first thing viewers see when browsing. For Shorts, thumbnails matter less because the Shorts feed shows the actual video playing, not a static image. But thumbnails still appear in some contexts: channel pages, search results, and when Shorts are embedded or shared. The API lets you upload custom thumbnails via the thumbnails.set endpoint. What it doesn’t clearly tell you:
  • Thumbnail processing happens separately from video processing. Your video might be ready while the thumbnail is still “pending.” Or the thumbnail upload might fail silently while the video succeeds.
  • Your channel needs to be verified (via phone) to upload custom thumbnails at all. If you’re building an application where users connect their own channels, you’ll encounter cases where thumbnail uploads fail because the user’s channel isn’t verified. The error message doesn’t always make this clear.
For Shorts specifically, many developers skip custom thumbnails entirely and let YouTube auto-generate them from the video. This works fine for the Shorts feed experience, and it’s one less thing to fail.

The Category Confusion

When uploading a video, you’re required to specify a categoryId. This is a numeric code representing the content category (Music, Gaming, Education, etc.). Here’s what the documentation doesn’t mention: not all categories are valid for all regions. If your user is in a region where a particular category isn’t available, the upload will fail with an unhelpful error. The categories.list endpoint lets you retrieve valid categories for a specific region, but most developers don’t think to check this until uploads start failing for international users. The safe approach: use category "22" (People & Blogs) as a default - it’s universally available. Or dynamically fetch valid categories based on the user’s channel region and present only those options.

The “Is It Actually a Short?” Mystery

Here’s a fun one: you upload a video that meets all the Short criteria (under 3 minutes, vertical aspect ratio), but YouTube doesn’t treat it as a Short. This happens. And the documentation offers no explanation for why. From what we’ve observed, YouTube has internal processing that determines Short eligibility beyond the basic criteria. Videos uploaded via API sometimes end up in a gray zone where they’re short-format but don’t appear in the Shorts feed or get the Shorts player. Adding #Shorts to the title or description seems to increase reliability, though Google has stated this shouldn’t be necessary. There’s also a timing element that’s poorly understood. Shorts uploaded during certain periods or to channels with certain characteristics seem to be classified differently. We’ve seen identical videos uploaded minutes apart get different treatment. The practical advice:
  1. Do everything right (correct aspect ratio, under 3 minutes)
  2. Include #Shorts in the description as insurance
  3. Accept that some percentage of uploads might not get Shorts treatment
  4. If consistent classification is critical, implement verification checks and retry logic

The Analytics Mismatch

If you’re pulling Shorts analytics via the API, prepare for confusion. The YouTube Analytics API wasn’t designed with Shorts in mind, and it shows. Shorts views are counted in the regular view metrics, but there’s no easy way to separate “Shorts views” from “regular video views” via the API. The Shorts shelf, Shorts feed, and direct Shorts playback are all aggregated. Some Shorts-specific metrics have been added over time (like views from the Shorts feed), but documentation lags implementation. Features might exist in YouTube Studio that aren’t yet exposed via API.
Our approach has been to pull what’s available, clearly label what the numbers represent, and not pretend we have more granularity than the API provides. Misleading users about their analytics is worse than admitting the platform has limitations.

The Survival Guide

After fighting with the YouTube Shorts API for the better part of two years, here’s the condensed wisdom:
  1. Use the standard video upload flow. Don’t look for Shorts-specific endpoints that don’t exist. Make your video vertical and short, and YouTube will figure it out.
  2. Build quota awareness into your architecture from day one. Track usage, implement limits, and apply for quota increases before you need them.
  3. Handle processing delays in your UX. Don’t promise instant playback. Show processing states. Poll for completion if you need to display the video immediately.
  4. Test with multiple regions and channel configurations. Edge cases involving categories, verification status, and regional restrictions will bite you if you only test with your own developer account.
  5. Add #Shorts to descriptions as insurance. It shouldn’t be necessary, but it seems to help with classification reliability.
  6. Expect things to change without notice. Google updates the API, changes quota costs, adjusts processing behavior, and modifies Shorts classification logic. Build with resilience in mind.
The YouTube Shorts API isn’t broken - it’s just designed for a different era, before Shorts existed, and adapted imperfectly. Understanding its quirks is the price of admission for building YouTube automation that actually works.
Don’t want to deal with any of this? At bundle.social, we handle quota tracking, processing delays, thumbnail logic, and all the classification quirks. You just tell us it’s a Short and we take care of the rest.

YouTube Platform Docs

Full YouTube API options including Shorts, analytics, and COPPA

Schedule YouTube Shorts

Complete guide to scheduling Shorts

API Documentation

Skip the complexity - one API for 14+ platforms