Markblox

What it is

Writers work in a rich-text editor instead of writing Markdown or committing to a repo. Content is stored and delivered through an API, so the reading side can be any framework, or none at all. The public repo is an example blog that consumes that API.

The challenge

The editor was the hard part. Rich text has to be stored in a form the API can serve to any frontend, so every custom block — code, callout, table, embed — has to survive the trip from editor state to stored content and back. Auth was the second piece: the dashboard needed sessions, while external programs needed keys that could be revoked.

How I solved it

• Tiptap's schema keeps each block as structured content rather than raw HTML, and the API returns that same shape.
• Custom blocks are added to the schema instead of sitting beside it, so the stored content and the rendered content agree.
• API keys are separate from user sessions; refresh tokens rotate, so a leaked token has a limited window.
• Webhooks fire after a publish, so integrations react to one event instead of polling for changes.

How it is built

• Next.js and TypeScript across the app and API layer.
• A Tiptap editor extended with custom blocks: code blocks, callouts, tables, images, and embeds.
• MongoDB for content and project storage.
• A dashboard for managing projects, posts, and access.

Access and integration

API keys give programs access to content, webhooks fire on publish events, and auth uses rotating refresh tokens so a long-lived session does not keep reusing the same token. The demo blog repo shows the consuming side.

Where it stands

The editor and the draft-to-publish flow work end to end, and early users can sign in. Pricing, self-hosting docs, and the public launch are still open work, which is why the site asks for early access rather than pretending the product is finished.