Your Content Is a Service Now: Cross-Site Feeds and oEmbed
#feeds#oembed#devlog#building-in-public#developer-tools#scsiwyg
David Olsson
scsiwyg has always had per-site RSS feeds. What it didn't have was a way to pull posts across multiple sites into a single stream, or embed a post from one site into another context.
Both of those are now live.
Cross-site feed
The /api/feed endpoint accepts a list of usernames and returns a merged, chronologically sorted feed of their public posts. This is useful for:
- Aggregation pages that pull from multiple team blogs
- Digest emails that cover several projects at once
- Dashboard views that surface the latest from a set of sites
- Any reader subscription that wants to follow an author across their sites
The feed is available in RSS and JSON Feed formats. Subscribe to it in any reader, or consume it programmatically in your own application.
oEmbed
The /api/oembed endpoint turns any public scsiwyg post URL into an embeddable card. Pass the post URL as the url parameter, and you get back the title, excerpt, author, publish date, and rendered HTML.
Platforms that auto-discover oEmbed endpoints — Notion, some CMS editors, custom embed surfaces — can embed scsiwyg posts natively without any extra configuration. The discovery metadata is in the <head> of every public post page.
Why both
A feed aggregates over time. An oEmbed embeds a specific piece. Together they let your content travel without friction.
A post you publish on one scsiwyg blog can:
- Appear in a cross-site digest feed
- Be embedded as a card in a Notion doc
- Render in a custom application's content section
- Be subscribed to by readers alongside posts from your other sites
None of that requires any action after publishing. Publish once, surface anywhere.
This is what headless means when it's also a content service — not just an API you query, but a platform that participates in the broader content ecosystem.