One Directus API behind a website, a newsletter, and an app

Field Notes Media publishes across a website, a newsletter, and a mobile app. Each had grown its own content setup: a CMS for the site, a separate tool for the newsletter, and hand-maintained JSON for the app. The same article was entered up to three times.

The problem

• Triple entry. Publishing a piece everywhere meant re-keying it into three systems, each with its own quirks.
• Drift. The three copies fell out of sync; a correction on the site did not reach the app.
• Developer dependency. Anything structural, such as a new content type or a change to how an article rendered in the app, was a ticket to engineering.

What we built

A single content platform on self-hosted Directus, with every surface as a client of one API.

• A content model designed with the editors (articles, series, contributors, and the reusable blocks that make up a piece) so an article is authored once and structured enough to render anywhere.
• The website: a Next.js front end consuming the Directus API, server-rendered, with Article and BreadcrumbList structured data and clean URLs.
• The newsletter: generated from the same content via a Directus Flow that assembles an issue and hands it to the email provider.
• The mobile app: a React Native app reading the same API, sharing types with the website.
• Roles: writers, editors, and a read-only API role for the app, with field-level permissions.

How it went

The model came first, built with the editorial team rather than for them, so the authoring experience matched how they already thought about their content. The three old systems were retired one at a time as each surface moved onto the new API.

The result

One API now sits behind all three surfaces. A piece is authored once; a correction propagates everywhere. New content types and layout changes are configuration in Directus, not a release, so editorial stopped filing tickets to engineering and the developers got their time back.