CMS With GraphQL API: Who Needs It and Which to Pick

Asking for a CMS with a GraphQL API gets you two very different kinds of advice. GraphQL enthusiasts hand you a list of every platform with a /graphql endpoint. Skeptics tell you REST was fine all along. Both dodge the actual decision, which is whether your project's query patterns justify GraphQL's setup cost, and only then which CMS serves it well.

Full disclosure before anything else: our own CMS is REST-only, so we have a horse in this race and it isn't the GraphQL one. That cuts both ways; it also means this post has to argue honestly or look silly.

TL;DR: Pick a GraphQL CMS when your frontend composes deeply nested content in single requests (posts with authors, categories, related items, and custom fields together), when multiple clients need different slices of the same content, or when your team's tooling is already GraphQL-native. The strong options in 2026: Payload and Strapi (self-hosted, GraphQL + REST both), Directus (GraphQL over your own database), Hygraph (GraphQL-native SaaS), and WPGraphQL if you're on WordPress. If your queries are "give me the post list, give me one post," REST does it with less machinery.

What GraphQL Buys You in a CMS, Concretely

The generic pitch (ask for exactly what you need) undersells the real CMS use case. Content is a graph: a post has an author, categories, related posts, and each of those has its own fields. REST answers with either fat endpoints returning everything or three round trips. GraphQL answers in one query shaped like your component tree:

query {
  post(slug: "launch-week") {
    title
    author { name, avatar }
    categories { name, slug }
    related(limit: 3) { title, slug, heroImage }
  }
}

One request, no over-fetching, and a typed schema your IDE reads. For component-heavy frontends where each component declares its own data needs, that mapping is the whole appeal.

The costs are equally concrete. Caching gets harder: every query hits the same URL, so the HTTP caching and CDN tricks that make REST content APIs nearly free stop applying without extra work (persisted queries, edge-aware GraphQL layers). Complexity limits, depth limits, and query cost analysis become your problem, because a public GraphQL endpoint that lets strangers write arbitrary nested queries is a denial-of-service invitation. And debugging moves from "look at the URL" to tooling.

We wrote the deeper protocol comparison in REST vs GraphQL for API-first CMS; this post takes the choice as open and looks at platforms.

The Platforms Worth Shortlisting

Payload treats GraphQL as a first-class output: define collections in TypeScript, get REST and GraphQL APIs generated with full types. Self-hosted, MIT, runs inside a Next.js app since v3. The strongest pick for TypeScript teams who want GraphQL without a SaaS bill.

Strapi ships GraphQL as an official plugin alongside REST. The visual content-type builder means non-developers extend the schema, and the ecosystem is the largest in open-source headless. You operate Node infrastructure and ride the major-version upgrade cycle; our Strapi alternative guide covers when that wears thin.

Directus generates GraphQL (and REST) over any SQL database you point it at, which makes it the pick when the content already lives in Postgres tables. Check the BSL license threshold (free under $5M organizational revenue) before an agency standardizes on it.

Hygraph is GraphQL-native SaaS, schema-first with content federation features REST platforms don't attempt. It's also enterprise-priced beyond the free tier, and your content lives on their infrastructure; the UnfoldCMS vs Hygraph comparison maps that trade.

WPGraphQL deserves its mention: if the content is already in WordPress, the plugin produces a competent GraphQL layer without a migration. It inherits WordPress's plugin-stack maintenance, covered in our headless WordPress with React breakdown.

When REST Is the Right Answer to the GraphQL Question

Some searches for "CMS with GraphQL API" are really searches for "modern CMS with a good API," and those are different specs.

If your frontend fetches a post list, renders a post page, shows a menu, and searches, your query patterns are flat. REST endpoints answer each in one request, CDNs cache them by URL for free, and curl debugs them. Adding GraphQL to that project adds a query language, a security surface, and a caching problem to requests that were already one round trip.

That flat-query case is what UnfoldCMS builds for: /api/v1 REST endpoints for posts, pages, categories, menus, settings, and search, token auth, webhooks for rebuilds, on $5/month hosting with one-time pricing. No GraphQL, deliberately, and if the section above described your data needs, you'd never miss it. If the nested-query example earlier made you nod, pick Payload or Strapi instead; a REST-only CMS under a genuinely graph-shaped frontend produces exactly the round-trip waterfall GraphQL exists to fix.

The test I give teams: write down your five most complex real queries. If three need nesting past two levels, GraphQL earns its keep. If they're all lists and single items, it's résumé-driven architecture.

Hardening a Public GraphQL Endpoint

If you pick the GraphQL route, the endpoint's security work starts the day it goes public, so here's the checklist that separates production setups from incident reports.

Depth and complexity limits come first. GraphQL's flexibility means a stranger can write a query nesting relations ten levels deep, and your database will faithfully attempt it. Every platform above supports depth limiting (typically capped around 5 to 8 for content schemas) and query cost analysis; turn both on before launch, not after the first slow-query alert.

Persisted queries close the biggest hole for production frontends. Instead of accepting arbitrary query strings, the server accepts only pre-registered query hashes that your build generated. Strangers lose the ability to compose novel queries entirely, and you get URL-level caching back as a bonus, which recovers most of the CDN economics REST had by default.

Disable introspection in production, or gate it behind auth. Introspection is wonderful in development and a free schema map for anyone probing you in production. Pair it with rate limiting on the endpoint (the same budget you'd give a REST API applies) and alerting on query cost spikes, which tend to be the first visible sign someone found your endpoint interesting.

None of this is exotic; each platform documents its version of every step. The point of listing it is the aggregate: this checklist is the standing tax GraphQL charges over REST for public content APIs, and it belongs in the estimate when the team votes on protocols. Teams that budget it ship fine. Teams that discover it in production write the postmortems the rest of us learn from.

FAQ

Which self-hosted CMS has the best GraphQL support?

Payload, for generated types and schema-as-code discipline. Strapi, for ecosystem and non-developer schema editing. Directus, when the source of truth is an existing SQL database. All three also expose REST from the same content, so you're not locked into the choice per-client.

Does WordPress support GraphQL?

Through WPGraphQL, a mature free plugin. It maps posts, pages, taxonomies, and (with extensions) ACF fields into a queryable schema. You keep WordPress's hosting and plugin maintenance profile underneath.

Is GraphQL faster than REST for a CMS?

For nested content needs, usually: one request replaces several. For flat requests, REST is at least as fast and caches far more easily on CDNs. Speed follows your query shapes, not the protocol's reputation.

Can a public GraphQL CMS endpoint be secured?

Yes, with work REST doesn't demand: depth limits, query cost analysis, persisted queries for production clients, and rate limiting. Every platform above documents its hardening steps; skipping them on a public endpoint is the common mistake.

Can I use GraphQL and REST from the same CMS?

On Payload, Strapi, and Directus, yes: both APIs serve the same content, so the website can take cached REST while an app composes GraphQL queries. Pick per client instead of per project.

Does GraphQL work with static site generators?

Well, actually: build-time queries fetch everything in few requests and the caching concerns disappear because output is static. Gatsby made this pattern famous; Astro and Next.js consume GraphQL CMS endpoints at build time just as comfortably.

Methodology

Platform capabilities reference official documentation in July 2026: payloadcms.com, strapi.io (GraphQL plugin docs), directus.io, hygraph.com, and wpgraphql.com. Licensing notes reflect each project's published terms, including Directus's BSL 1.1. UnfoldCMS is REST-only by design; we build it, we said so up front, and the recommendation logic above sends genuinely graph-shaped projects to our competitors by name.