I built a screenshot API — looking for feedback

Full-page capture on virtualized lists is the case that trips up a lot of scroll-and-stitch approaches. Once a page unmounts DOM nodes that scroll out of view, like most infinite-feed UIs built with react-window or similar, each stitched slice only has whatever happened to be mounted at that scroll position. You end up with duplicate rows or gaps in the final image instead of an error, so it's easy to miss in testing since a normal blog or docs page never triggers it.

A dedicated test page with one of those would catch it before a user reports blank rows in production.

Nice pivot toward monitoring — that’s where a lot of screenshot API usage actually sticks.

One thing that bit me shipping in this category: without a short TTL cache, cron/n8n retries burn credits fast. Also worth making “failed render = free” explicit on the pricing page; buyers compare ScreenshotOne/Urlbox entry jumps hard.

I went the cheap URL→image route myself (Snap: https://snap.flyhold.in — 200 free/mo, $9/5k) with ≤1h cache hits free. Curious how you’re handling cookie banners on the monitoring path.

Quick update:

I pivoted from just screenshot API → visual monitoring + competitor tracking.

Would love feedback 🙏

Nice idea. One quick thing — if your API response time isn’t optimized or cached, it could become a bottleneck at scale. Might be worth adding caching or queueing depending on usage.