YouTube still runs a public PubSubHubbub hub — renamed WebSub, same protocol — that pushes a notification the moment a channel publishes. It's free, and it's real. It's also more plumbing than it looks: a public callback, a verification handshake, and a subscription that quietly expires every few days if nothing renews it. This page lays out exactly what the DIY path involves and where a hosted webhook trades push latency for less to maintain. VidProxy doesn't use WebSub itself — it polls YouTube's RSS feed — and we say so plainly below.
A push notification hub. Subscribe to a channel's topic URL and the hub POSTs a small Atom entry to your callback the moment that channel publishes or edits a video. Free, no API key — but the plumbing is yours.
Not a WebSub client — VidProxy polls each channel's public RSS feed on your plan's interval and POSTs the new video, transcript included, to a URL you control. No callback to host, no lease to renew.
Subscribing to the hub is genuinely one HTTP form post. What comes after that is the part that decides whether this is a good use of a week.
Google's hub caps hub.lease_seconds at 432,000 seconds — five days. When a subscription lapses, notifications simply stop. Nothing errors, nothing logs, and there's no callback telling you the lease is gone. The integration looks fine until someone notices a channel has been quiet for a week that it clearly wasn't. You need a scheduled renewal job, and that job has to be more reliable than the thing it's renewing.
The hub's payload is a few lines of Atom: a video ID, a title, a channel ID, two timestamps. That's it. If what you actually want is the spoken content of the video — for a RAG pipeline, a summarizer, a monitoring tool — the notification is just the starting gun. Fetching captions is a separate job, and it's the one that fights back: YouTube blocks caption requests from data-center IP ranges, so code that works from a laptop returns empty from Render, Fly, or AWS.
A public callback needs to stay reachable indefinitely — a URL that 500s for long enough gets dropped by the hub. It has to survive redeploys, and it has to answer the verification handshake with the exact challenge string, echoed back as plain text, or the subscription silently fails. Polling a feed has none of that: no inbound traffic to secure, no handshake, no lease clock. The tradeoff is latency, not correctness — polling is a few minutes behind push, not more likely to break.
We want to be direct about this rather than let the comparison imply otherwise: VidProxy does not implement PubSubHubbub or WebSub. It monitors each subscribed channel's public RSS feed on an interval set by your plan — 10 minutes on Free, 5 minutes on Starter, 2 minutes on Pro and Agency. That is a real, honest tradeoff against the hub's near-instant push, not a hidden one.
What polling buys back is everything the hub payload doesn't give you. Because VidProxy already owns the fetch step, it fetches the transcript through a residential-IP proxy chain before delivering the webhook — the same captions request that returns empty from a data center. The payload arrives as one POST with the video metadata and the full transcript together, not a bare notification you then have to go fetch content for.
The hub's own delivery to your callback carries no documented retry or dedup contract for you to rely on — you build both. VidProxy's poller claims each delivery against a unique (subscription, video) row before it POSTs, so a video is never delivered twice to the same subscription even if two poll cycles overlap. A failed delivery is retried three times with backoff (2s, 10s, 30s) before it's recorded as failed and an admin alert fires.
By default, delivery also waits until the transcript is confirmed available (or a 24-hour hold expires) before firing your webhook, so you're not handed a payload racing an empty transcript field — that's configurable per subscription if you'd rather get the notification immediately.
| Capability | PubSubHubbub / WebSub (DIY) | VidProxy |
|---|---|---|
| Notification Delivery | ||
| Notification latency | ✓ Near real-time push | Polling interval — 2–10 min by plan |
| Public HTTPS callback required | ✕ Required | ✓ None needed |
| Hub verification handshake to implement | ✕ Required | ✓ N/A |
| Subscription renewal required | ✕ Every ~5 days | ✓ Nothing to renew |
| Duplicate notifications on video edits | ✕ Dedup is yours to build | ✓ Handled — exactly-once per video |
| Content | ||
| Transcript included in the notification | ✕ Metadata only | ✓ Full transcript + segments |
| Works from a data-center IP | Notification: yes. Captions: no | ✓ Residential proxy chain |
| AI summary + key takeaways | ✕ | ✓ Pro / Agency |
| Keyword filtering on transcript content | ✕ | ✓ Pro / Agency |
| Reliability & Ops | ||
| Delivery retries on your endpoint failing | No documented SLA from the hub | ✓ 3 retries, exponential backoff |
| Hold delivery until transcript is confirmed | ✕ N/A — no transcript | ✓ Optional, per subscription |
| Silent-failure risk if unmaintained | ✕ Lease expiry is silent | ✓ No lease to let lapse |
| Setup & Cost | ||
| Requires a Google Cloud project or API key | No | No |
| Requires hosting a public server | Required | No |
| Free to use | ✓ Free | ✓ Free tier — 1 channel + 10 transcript lookups/mo |
Subscribe to the hub yourself when the notification is genuinely all you need — you want to know a video exists, near-instantly, and you're comfortable owning a public callback, a renewal cron, and dedup logic for the life of the integration. It's free, it works, and for a small side project that's a fair trade.
Reach for a hosted webhook when what you actually want is the transcript, not just the notification — and you'd rather not run a public endpoint or track a five-day expiry clock to get it. VidProxy trades the hub's near-instant push for a short polling delay, and uses that same fetch step to hand you the transcript in the same payload.
Free tier, no credit card, no public server to host.
No credit card · Free tier forever