DEV Community: CHANDAN

Part 2: I Broke Out of YouTube My Bot Now Hits Instagram & Twitter/X Too (3 Platforms, 3 Completely Different Protection Models)

CHANDAN — Mon, 02 Nov 2026 06:20:04 +0000

📖 Part 1 is here — read it first:
How I Built a Telegram Bot That Downloads YouTube Music & Videos (Up to 2 GB)

🤖 Try the live bot: (https://t.me/songsuperzxbot)
📦 Source code: github.com/chandan0000001/music-video_telegrambot

Someone sent me a message after Part 1 went live.

"Can it do Instagram Reels?"

Short answer at the time: no.

Slightly longer answer after a few weeks of work: yes, and also Twitter/X, and also Instagram Stories, profile pictures, highlights, and posts. But getting there was a completely different problem from YouTube — and I mean completely different. Three platforms. Three protection models. Three sets of rules about what you can fetch without authentication, what you can't, and what will quietly rate-limit you into oblivion if you're not careful.

This is the story of how I expanded the bot, what I learned about how Instagram and Twitter/X actually protect their content, and the architectural changes that come with supporting multiple platforms in one bot.

What the Bot Already Does (Quick Recap)

Before I get into the new stuff — if you haven't read Part 1, the short version:

The bot is a production-grade Telegram bot built with Python 3.11, aiogram 3, FFmpeg, and SQLite WAL mode. It searches YouTube, lets users pick from the top 5 results, and downloads audio in MP3/M4A/WAV up to 320kbps or video in MP4 up to 1080p. The clever parts are:

yt-dlp's Signature Cipher bypass — reverse-engineers YouTube's JS player to reconstruct the real stream URL
Smart 2 GB delivery — files under 48 MB go via HTTP Bot API instantly; larger files use native MTProto
Intel VAAPI hardware acceleration — FFmpeg transcodes using the GPU render node, ~10x faster than CPU
Full admin panel — stats, ban/unblock, broadcast, CSV export, live queue view
30 automated tests — URL validation, FFmpeg pipeline, rate limiting, cancellation, database

That foundation is what Part 2 is built on. Now let's talk about why adding Instagram and Twitter/X was harder than just "swap yt-dlp's input URL."

Why Three Platforms is an Architecture Problem, Not Just a Feature

When I built the YouTube handler, it was a one-platform world. The whole flow assumed: user sends query or YouTube URL → validate → download → deliver.

The moment you add Instagram and Twitter/X, that assumption breaks. You now need:

A URL router — detect which platform a URL belongs to before doing anything else
Platform-specific authentication — Instagram requires a session cookie; YouTube needs cookies for age-restricted content; Twitter/X can sometimes do without
Platform-specific content types — YouTube has audio or video. Instagram has reels, stories, highlights, posts, and profile pictures. Twitter/X has videos, images, and posts with mixed media
Platform-specific rate limiting — YouTube is relatively forgiving. Instagram will silently downgrade your requests or temporarily block your IP if you hammer it. Twitter/X has changed its protection model more aggressively than any other platform in recent years

Here's the new routing layer that runs before any download starts:

import re
from enum import Enum

class Platform(Enum):
    YOUTUBE  = "youtube"
    INSTAGRAM = "instagram"
    TWITTER  = "twitter"
    UNKNOWN  = "unknown"

PLATFORM_PATTERNS = {
    Platform.YOUTUBE: re.compile(
        r'^https?://(www\.)?(youtube\.com/watch\?v=|youtu\.be/|youtube\.com/shorts/)[A-Za-z0-9_\-]{11}'
    ),
    Platform.INSTAGRAM: re.compile(
        r'^https?://(www\.)?instagram\.com/(p|reel|stories|tv|s)/[A-Za-z0-9_\-]+'
    ),
    Platform.TWITTER: re.compile(
        r'^https?://(www\.)?(twitter\.com|x\.com)/\w+/status/\d+'
    ),
}

def detect_platform(url: str) -> Platform:
    # SSRF guard — always first
    if re.match(r'https?://(localhost|127\.|10\.|192\.168\.|169\.254\.)', url):
        return Platform.UNKNOWN
    for platform, pattern in PLATFORM_PATTERNS.items():
        if pattern.match(url):
            return platform
    return Platform.UNKNOWN

The SSRF check runs before platform detection. An attacker sending http://192.168.1.1/admin disguised as any platform URL gets rejected at this layer, not inside any platform-specific handler.

Platform 1: YouTube (The One We Already Solved)

Covered in full in Part 1. The short summary of how YouTube protects streams:

Signature Cipher — stream URLs are scrambled via a JavaScript function that yt-dlp reverse-engineers from YouTube's player JS
n-parameter throttle — download speed is capped at ~50 KB/s unless you decrypt an "n" parameter from the same JS bundle
po_token — a newer proof-of-origin token embedded in browser sessions, requiring a valid cookies.txt to bypass

yt-dlp handles all three. Keep it updated and refresh cookies.txt every few weeks.

Platform 2: Instagram — Sessions, Stories, and Aggressive Rate Limiting

Instagram's protection model is fundamentally different from YouTube's. YouTube obfuscates stream URLs but serves them publicly. Instagram ties almost everything to authenticated sessions.

What's public vs what needs auth

No authentication needed:

Public post images and videos
Public Reels
Profile pictures (always public — served directly from Instagram's CDN)

Requires a valid Instagram session:

Stories (expire in 24 hours; private to logged-in users)
Highlights (archived stories; account-level access)
Content from private accounts

How Instagram serves content

When you watch a Reel in your browser, the actual video file is served from Instagram's CDN — URLs that look like:

https://scontent-iad3-1.cdninstagram.com/v/t50.2886-16/...?_nc_ht=scontent...&_nc_cat=...

These CDN URLs are time-limited and session-tied. They're embedded inside a JSON blob in the page's JavaScript bundle or fetched via an internal GraphQL endpoint. yt-dlp's Instagram extractor reverse-engineers these endpoints to pull the direct CDN URL.

For authenticated content (stories, highlights), the extractor needs a valid sessionid cookie — the same session token your browser uses when you're logged into Instagram.

Configuring Instagram in the bot

def get_instagram_opts(content_type: str, output_path: str) -> dict:
    base_opts = {
        'outtmpl': output_path,
        'quiet': True,
        'cookiefile': 'instagram_cookies.txt',  # must contain valid sessionid
        'http_headers': {
            'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36',
        },
    }

    if content_type in ('reel', 'video', 'post'):
        base_opts['format'] = 'bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]'
    elif content_type == 'story':
        base_opts['format'] = 'best'  # stories are single-stream
    elif content_type == 'profile_picture':
        base_opts['format'] = 'best'

    return base_opts

The rate limiting trap

Instagram rate-limits by IP and by session. If you download too many items in quick succession using the same session cookie, Instagram starts returning 401 Unauthorized errors — even for public content — or silently serves lower-quality versions.

My fix: per-platform cooldown timers. Instagram downloads enforce a 15-second minimum gap between requests from the same session. This is longer than the YouTube cooldown (10 seconds) specifically because Instagram's rate limiting is less forgiving and harder to detect when it's happening.

PLATFORM_COOLDOWNS = {
    Platform.YOUTUBE:   10,   # seconds between requests
    Platform.INSTAGRAM: 15,   # Instagram rate-limits harder
    Platform.TWITTER:   8,
}

Profile pictures — the easy one

Profile pictures are the simplest Instagram download. They're always public, always served directly from the CDN, and don't require authentication:

https://instagram.com/{username}/?__a=1

The JSON response contains graphql.user.profile_pic_url_hd — a direct image URL. No cipher, no session required, just a clean HTTP GET.

Platform 3: Twitter/X — Bearer Tokens and a Platform That Keeps Moving

Twitter's 2023 pivot to X — and the dramatic changes to API access that came with it — made this the most technically interesting platform to support.

How Twitter/X protects video content

Twitter/X video is delivered as HLS streams (HTTP Live Streaming). When you watch a video in a tweet, the player fetches an M3U8 playlist that lists the actual video segments:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=2176000,RESOLUTION=1280x720
https://video.twimg.com/ext_tw_video/.../720x1280/...m3u8
#EXT-X-STREAM-INF:BANDWIDTH=832000,RESOLUTION=640x360
https://video.twimg.com/ext_tw_video/.../360x640/...m3u8

The M3U8 playlist URL itself is embedded in the tweet's card data, which is fetched from an internal API endpoint:

https://api.twitter.com/1.1/statuses/show.json?id=<tweet_id>

This endpoint requires a Bearer token — an authentication token that Twitter's own web client sends with every request. yt-dlp extracts this bearer token from Twitter/X's JavaScript bundle (the same approach it uses for YouTube's cipher — find the token in the JS, use it for requests).

What happened in 2023

When Elon Musk took over Twitter and rebranded it to X, free API tier access was almost entirely removed. Third-party apps that relied on Twitter's public API were killed. Nitter (the privacy-friendly Twitter frontend) started failing. Many download tools broke.

yt-dlp adapted by switching to the "guest API" — an unauthenticated path that Twitter/X still exposes for public content, using a guest token that gets issued when you visit the site without being logged in. This guest token approach still works for public tweets.

Handling tweets with multiple images

A tweet can have 1-4 images. When a user sends a tweet URL with multiple images, the bot downloads all of them and sends them as a Telegram media group:

async def handle_twitter_images(url: str, message: Message):
    with yt_dlp.YoutubeDL({'quiet': True, 'skip_download': True}) as ydl:
        info = ydl.extract_info(url, download=False)

    if 'entries' in info:
        # Multiple images — send as album
        media_group = []
        for entry in info['entries']:
            img_url = entry.get('url')
            if img_url:
                media_group.append(InputMediaPhoto(media=img_url))

        if media_group:
            await message.answer_media_group(media=media_group)
    else:
        # Single image or video
        ...

Telegram supports sending up to 10 items in a media group, which covers Twitter/X's 4-image maximum comfortably.

The Content-Type Detection System

Instagram URLs carry information about content type in the path:

URL pattern	Content type
`instagram.com/p/{id}/`	Post (image or video)
`instagram.com/reel/{id}/`	Reel (short video)
`instagram.com/stories/{user}/{id}/`	Story
`instagram.com/s/{highlight_id}/`	Highlight
`instagram.com/{username}/`	Profile (→ profile picture)
`instagram.com/tv/{id}/`	IGTV (long video)

def detect_instagram_content_type(url: str) -> str:
    if '/reel/' in url:    return 'reel'
    if '/stories/' in url: return 'story'
    if '/p/' in url:       return 'post'
    if '/s/' in url:       return 'highlight'
    if '/tv/' in url:      return 'video'
    # If it's just instagram.com/{username}/ — profile picture
    if re.match(r'https?://(www\.)?instagram\.com/[^/]+/?$', url):
        return 'profile_picture'
    return 'unknown'

The bot surfaces a different keyboard to the user depending on content type. A Reel shows "Download Video" and "Download Audio". A Story just shows "Download". A profile URL shows "Download Profile Picture". No unnecessary choices for things that have only one format.

Updated Supported Platforms

Here's where the bot stands now:

Platform	Content Types	Auth Required
YouTube	Music search, Audio (MP3/M4A/WAV), Video (144p–1080p)	cookies.txt (age-restricted only)
Instagram	Reel, Video, Post, Story, Highlight, Profile Picture	sessionid cookie (stories/highlights)
Twitter / X	Video, Post images (up to 4), GIF	None (public tweets)

All three platforms route through the same pipeline:
URL → platform detection → SSRF guard → content type detection → platform-specific yt-dlp config → FFmpeg → smart delivery (HTTP or MTProto) → cleanup.

What I Learned Building This

Instagram is the hardest platform to stay compatible with. YouTube breaks when they rotate the cipher — that's a known, predictable event that yt-dlp patches. Instagram breaks when they change their internal GraphQL schema, which happens without announcement and with no public documentation to reference. Two of my three "bot is down" incidents since adding Instagram support were Instagram schema changes, not YouTube.

Twitter/X's guest API is fragile. It works today. X has shown zero interest in maintaining compatibility with third-party tools, and the guest API could be deprecated at any point. I handle this by catching yt-dlp errors and returning a clear message to users — "this video may not be downloadable" — instead of silently failing.

Per-platform rate limiting is non-negotiable. A single rate limiter across all platforms was my first approach. It was wrong. Instagram needs longer cooldowns than YouTube. Twitter/X is somewhere in the middle. Platform-specific cooldown values aren't premature optimization — they're the difference between a bot that works reliably and one that gets session-banned after 20 minutes.

yt-dlp is genuinely impressive. One library, three completely different platform protection models, maintained by a community that ships patches sometimes within hours. The right posture when building on top of it: keep it updated, wrap all extractor calls in robust error handling, and never assume a config that works today will work in two weeks.

Try It

The bot handles all three platforms now. Drop a YouTube link, an Instagram Reel, or a Twitter/X video URL and it figures out the rest.

Try it: @songsuperzxbot

Source code: github.com/chandan0000001/music-video_telegrambot

Part 1 (YouTube deep-dive): dev.to/chandan0000001/...

Questions about Instagram's session handling, Twitter/X's HLS parsing, or anything else — drop them in the comments.

Updated feature Just added Instagram , X or twitter video Download

CHANDAN — Mon, 02 Nov 2026 05:55:30 +0000

CHANDAN

Nov 1

How I Built a Telegram Bot That Downloads YouTube Music & Videos (Up to 2 GB) And How yt-dlp Actually Bypasses YouTube's Protection

#python #telegram #ai #opensource

5 min read

How I Built a Telegram Bot That Downloads YouTube Music & Videos (Up to 2 GB) And How yt-dlp Actually Bypasses YouTube's Protection

CHANDAN — Sun, 01 Nov 2026 05:19:08 +0000

Live Bot: @songsuperzxbot

Source Code: github.com/chandan0000001/music-video_telegrambot

HD Demo: Watch on Streamable

I built a Telegram bot that downloads music and videos from YouTube and I want to walk you through exactly how it works, including the part that most tutorials skip: how yt-dlp actually gets past YouTube's stream protection.

I built a Telegram bot that downloads music and videos from YouTube — and I want to walk you through exactly how it works, including the part that most tutorials skip: how yt-dlp actually gets past YouTube's stream protection.

You can try the live bot here: @songsuperzxbot on Telegram
Full source code: github.com/chandan0000001/music-video_telegrambot

The Problem With Every Other Telegram Music Bot

Most Telegram music bots you find online have the same three problems:

They stop working after a few days because YouTube changes something
They hit Telegram's 50 MB limit and either fail silently or send a compressed garbage file
They run on a single thread, so if three people use it at once, everyone waits

I wanted to fix all three. Here's how.

How YouTube Stream Extraction Actually Works (The "Bypass" Explained)

This is the part nobody explains properly. When you open a YouTube video in your browser, the actual MP4/audio stream isn't directly accessible at a clean URL. YouTube obfuscates it in two ways:

1. Signature Cipher
YouTube wraps the stream URL inside a JavaScript function that scrambles the signature parameter. The raw URL looks something like this:
(https://rr3---sn-xxx.googlevideo.com/videoplayback?...&sig=SCRAMBLED_SIG)

The actual playable URL only works when you un-scramble that signature. YouTube's own player does this in the browser using a JavaScript function it downloads fresh every session. The function changes regularly to break scrapers.

yt-dlp's solution: It downloads YouTube's player JS, extracts the current cipher function, reverse-engineers the transformation steps (they're always a combination of reverse, swap, and splice operations), and applies them to reconstruct the real signature. This is why yt-dlp updates so frequently — YouTube rotates this function.

2. n-parameter Throttling
Even with a valid signature, YouTube adds an n parameter to the URL that limits download speed to about 50 KB/s if not decrypted. yt-dlp decrypts it using the same JS extraction approach, unlocking full speed.

In my bot, I run yt-dlp with 8 parallel fragment streams to max out the download speed:

ydl_opts = {
    'concurrent_fragment_downloads': 8,
    'cookiefile': 'cookies.txt',  # handles age-restricted content
    'quiet': True,
}

The cookies.txt handles age-restricted videos. You export your browser cookies with the Get cookies.txt extension and drop the file in the bot's folder.

What Happens After Download: The FFmpeg Pipeline

Once yt-dlp pulls the raw stream, FFmpeg takes over. For audio:

# Extract audio and convert to MP3 at chosen bitrate
ffmpeg -i input.webm -vn -ab 320k -ar 44100 output.mp3

For video, I use Intel VAAPI hardware acceleration when available, which runs about 10x faster than CPU encoding:

# Hardware-accelerated H.264 encode
ffmpeg -vaapi_device /dev/dri/renderD128 \
       -i input.webm \
       -vf 'format=nv12,hwupload' \
       -c:v h264_vaapi \
       -c:a aac output.mp4

On machines without VAAPI (Windows, Termux, most VPS), it falls back to software encoding automatically.

The 50 MB Telegram Limit — How I Send Up to 2 GB

Standard Telegram bots can only send files under 50 MB. Most bots just compress the video into a potato-quality file. Mine doesn't.

The routing logic works like this:

Under 48 MB → Send directly via standard Bot API. Instant.
Over 48 MB, MTProto configured → Use native MTProto client (Telethon) which supports up to 2 GB natively with your API ID and hash from my.telegram.org
Over 48 MB, no MTProto → Split the file into 44 MB chunks using lossless stream copy (zero re-encoding, zero quality loss, runs at disk speed)

The lossless chunking command looks like this:

ffmpeg -i input.mp4 -c copy -f segment \
       -segment_size 46137344 chunk_%03d.mp4

No quality loss. No waiting for re-encode. Just pure stream splitting.

Database: Why SQLite Was the Right Choice

I went with SQLite in WAL mode instead of PostgreSQL. For a single bot, this was the right call:

WAL mode means readers and writers don't block each other — critical when multiple users are downloading simultaneously
Zero ops overhead — no separate database server to manage
Atomic crash recovery built in

Every connection opens with:

conn.execute("PRAGMA journal_mode=WAL")
conn.execute("PRAGMA foreign_keys=ON")

The schema tracks every user, every search, every download, and aggregated stats in real time.

Security: Blocking SSRF Attacks

When users send URLs, a naive bot would just forward them to yt-dlp. That's dangerous — someone could send http://192.168.1.1/admin and probe your internal network.

My validator rejects anything that isn't a real YouTube URL:

YOUTUBE_REGEX = re.compile(
    r'^https?://(www\.)?(youtube\.com/watch\?v=|youtu\.be/|'
    r'youtube\.com/shorts/)[A-Za-z0-9_\-]{11}'
)

def validate_url(url):
    # Block private IP ranges first
    if re.match(r'https?://(localhost|127\.|10\.|192\.168\.|169\.254\.)', url):
        return False
    return bool(YOUTUBE_REGEX.match(url))

Filenames are also sanitized before hitting the filesystem to prevent path traversal:

safe_name = re.sub(r'[^\w\-_\. ]', '_', raw_name)[:200]

Running 24/7 on Android (Yes, Really)

One of the coolest deployment options is Termux on Android. No root required:

pkg install python ffmpeg -y
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
termux-wake-lock
python bot.py

The termux-wake-lock command prevents Android from killing the process when the screen turns off. I ran it for a week on an old Redmi phone and it handled hundreds of downloads without a single crash.

The Test Suite: 30 Tests in 4 Seconds

Everything is tested — URL validation, filename sanitization, FFmpeg processing, rate limiting, cancellation, and the database:

pytest tests/ -v
# 30 passed in 4.01s

The cancellation test is my favourite — it verifies that hitting the Cancel button actually kills both the yt-dlp subprocess AND the FFmpeg process immediately, then confirms the temp directory is cleaned up. No zombie processes.

Try It Yourself

Live bot: https://t.me/songsuperzxbot on Telegram
Source code + full setup guide: github.com/chandan0000001/music-video_telegrambot

If you have questions about the yt-dlp cipher extraction, the MTProto upload integration, or running it on Termux, ask in the comments. Happy to go deeper on any part.