API-first FAQ vs the CMS approach

There are two ways to manage FAQ content. One is older, more familiar, and obvious to anyone who has used a CMS in the last fifteen years. The other is newer, more constrained, and the one we bet on when we built thefaqapp.

The CMS approach: your FAQ content lives inside a tool. Help Scout, Zendesk Guide, Document360, a WordPress plugin, a stand-alone help-center SaaS. You log into the tool, write your content there, and the tool hosts the resulting pages. Your customers visit those pages on the tool’s domain or on a subdomain the tool routes for you.

The API-first approach: your FAQ content lives in a database with an HTTP interface. You write to the API (or to a dashboard that wraps it). Your product reads from the API and renders the result wherever it makes sense — on your marketing site, inside your app, as a popover in your customer-facing UI, as a tool in your AI agent.

Why the CMS approach worked for so long

The CMS approach was the right call for a long time. In 2015, building “a help center page that looks good and ranks on Google” from scratch took weeks. The CMS tool gave you templates, hosting, search, basic SEO, and an admin UI in exchange for one constraint: your content lives there, on the tool’s terms.

Two things changed.

The first is that frontend tooling got dramatically better. In 2025, “a help center page that looks good and ranks on Google” is one Next.js route, one Tailwind component, and a query against a JSON API. The hard part used to be making the content look right; that part has collapsed.

The second is that the surfaces FAQ content lives on multiplied. It’s not “the help page” anymore. It’s the help page, an in-app help popover, a chatbot grounded on the same content, an AI agent that uses FAQ entries as retrieval, an iframe embedded on a partner site, a print-out for a sales kit. The “tool hosts the page” model fights all of these.

The constraint of the API-first approach

The API-first approach has one constraint and it’s a real one: you have to render the content yourself. The tool doesn’t ship you a pre-built page. There’s no template gallery. If you want a “card grid of FAQ topics with search and an expandable accordion,” you write it.

For a non-developer org, that’s a hard sell. For a product team with engineers, it’s the part you wanted to control anyway. The CMS template gallery is a feature for the audience that needs a template; for the audience that doesn’t, it’s a constraint.

Which is to say: API-first FAQ infra isn’t a strict improvement over CMS FAQ infra. It’s a different choice for a different team. We’re building for the second team.

What an API-first FAQ looks like in practice

import { createFAQClient } from "@faqapp/core";

const faq = createFAQClient({
  apiKey: process.env.FAQAPP_API_KEY!,
  organizationSlug: "acme"
});

// Anywhere — RSC, route handler, edge function, Node script
const { data: questions } = await faq.questions.list({
  category: "billing",
  status: "published"
});

That’s it. Render the result in JSX, in Markdown, in your AI agent’s tool definition, in a printed PDF. The data layer doesn’t care.

The interesting question isn’t “is this faster than logging into Zendesk.” For a single page, it isn’t. The interesting question is: “when you’re building the third surface that needs FAQ content (the in-app help popover after you already shipped the marketing page and the chatbot), does the API-first version save engineer-weeks?”

We think the answer is yes. That’s the bet.

Where we land

If you’re a small SaaS team shipping product on a modern stack, an API-first FAQ infrastructure costs you nothing to evaluate and saves you the next year of “let me embed this Zendesk iframe in our product” decisions. Try the SDK. See if the constraint feels like a constraint or like the part you wanted anyway.

If you’re a content team without engineers, keep using the CMS. It’s the right tool for that team. We’re not coming for you.