All releases

Public docs API + /share on simpleproduct.dev (dogfooded)

Public docs API + /share on simpleproduct.dev (dogfooded)

Every published doc in your workspace now has a stable public URL, no matter what type it is — and we built /share on simpleproduct.dev itself to prove the API does what it says.

The public docs API: type is now optional

Previously the public docs endpoint required a type query param. Any doc without a type — or whose type wasn't one of the "known" system types like blog or release — was unreachable through public surfaces. That made the whole publish flow narrower than it needed to be.

New shape:

GET /api/v1/docs/public/<slug>?workspace=<ws>             → doc by slug, any type
GET /api/v1/docs/public/<slug>?workspace=<ws>&type=<t>    → guard rail; 404 if doc.type !== <t>
GET /api/v1/docs/public?workspace=<ws>                    → all published, any type
GET /api/v1/docs/public?workspace=<ws>&type=<t>           → filter to one type

Slugs are now unique per workspace (not per (workspace, type)), so a slug alone uniquely identifies a doc. Type, when you do pass it, is purely an optional filter — never a disambiguator, never required.

SP dogfoods it: /share/<slug>

We added a /share route on simpleproduct.dev that renders any published doc via the public REST API — exactly the same fetch a customer would make from acme.com. No special workspace access, no internal Convex path, no auth header. The publish button is the auth.

Try it: a feedback review we wrote for Andrew Harrison at Stable Kernel — published as a regular doc in our SP workspace, with an embedded interactive slide-deck summary at the top. Same fetch you could make from your own site.

html-render code blocks now auto-resize

The html-render fenced-code block (introduced previously) sandboxes plain HTML/CSS/JS in an iframe — useful for embeds like the slide deck above. Until now the iframe was clamped at 200px regardless of content, so tall content got an inner scrollbar and felt small.

The iframe now sizes itself to its content via postMessage, with ResizeObserver and MutationObserver keeping it accurate as content reflows (slide decks switching slides, expanding panels, etc.). Sandbox unchanged: allow-scripts only, no same-origin access.

Why this matters (and how we use it ourselves)

Two of the things we say about Simple Product are:

  1. "Your product team's content can live next to your product work, not stuck in a separate marketing/CMS tool."
  2. "Any customer can pull that content into their own site."

We needed to prove #2 — and now we have. The /share route on simpleproduct.dev is literally the dogfood: we built it the way any customer would build their own equivalent on acme.com, with the same public API and the same workspace-slug-based fetch. We publish docs internally (release notes, customer-specific feedback reviews, blog posts, anything), and they're immediately shareable at simpleproduct.dev/share/<slug> — for visitors, customers, partners, whoever.

For our own use case it means: write a customer a thoughtful feedback review inside SP, embed a slide deck if it helps, hit publish, send them the URL. The whole loop — capture → write → publish → share — lives in one workspace.

For yours: same API, same call shape, just workspace=<your-slug> instead of sp. A customer-facing changelog, a public docs section, individual share links for customer reviews — anything you can author as a doc in SP, you can render on your own site with one fetch.

Try it yourself

  • curl "https://simpleproduct.dev/api/v1/docs/public?workspace=sp&limit=5" — list our recently published docs
  • curl "https://simpleproduct.dev/api/v1/docs/public/<slug>?workspace=sp" — fetch a single one by slug
  • Or visit any of the /share/<slug> URLs we publish from now on