feedhook · compare
Getting notified of new YouTube videos: the three real options
You're building something that needs to react when a channel publishes — a
content pipeline, an agent, an alerting tool. There are exactly three ways to know, and they
trade off very differently.
| Poll the Data API | Run WebSub yourself | Feedhook |
|---|
| Latency | your poll interval (minutes–hours; quota forces it up) | ~8s (push) | ~8s (push) + hourly sweep backstop |
| YouTube API quota | 100 units/search call — polling 50 channels hourly burns the free 10k/day | none | none |
| Infrastructure you run | cron + state | public always-up endpoint, hub handshakes, lease renewals every ~5 days, XML parsing, retries, missed-push recovery | none — one POST |
| Missed events | caught next poll | lost unless you also poll | hourly reconciliation sweep; failed deliveries kept + redeliverable |
| Verification | — | build it | signed deliveries (HMAC), per-attempt logs, test pings |
| Cost | free (quota-bound) | your server + your time | free for 1 feed · $9/mo for 10 |
When you should NOT use Feedhook
Honesty over conversion: if you need hundreds of feeds at scale, run WebSub
yourself — the plumbing is annoying but well-documented, and at that scale owning it is
correct. If a daily batch is fine for your product, a simple Data API poll is the least
moving parts. Feedhook is for the middle: you depend on minutes-not-hours freshness across a
handful of channels and don't want to babysit infrastructure.
What Feedhook actually does
YouTube already pushes — every channel feed supports WebSub (PubSubHubbub),
free. Almost nobody uses it because of the plumbing. Feedhook does the plumbing once:
subscriptions, handshakes, ~5-day lease renewals, signature verification, parsing, signed
delivery with 8 retries over ~9 hours, an hourly missed-push sweep, delivery logs, and
redelivery. Live numbers: /metrics. Full contract: /docs.
← a wall on walls.sh