WordPress REST API: Good Enough for Most Headless Clients

Every time a prospect asks me for a headless CMS, I ask what they actually need. Half the time the answer is: a normal blog that a Next.js frontend can consume. For that, WordPress's built-in REST API is enough. No separate CMS, no extra hosting, no new admin for the client to learn.

What the Built-in API Gives You

Every post, page, custom post type, category, and tag is automatically exposed as JSON. Without any plugins, you can hit /wp-json/wp/v2/posts and get a paginated feed.

curl https://client-site.com/wp-json/wp/v2/posts?per_page=10 | jq '.[].title'

That one-liner gives a Next.js frontend everything it needs for a blog listing.

The Pattern I Ship

For the last three headless WordPress projects I've done, the architecture was identical:

• WordPress on modest shared hosting for admin and content
• Next.js on Vercel consuming /wp-json/wp/v2/posts at build time
• Revalidation webhook triggered by a WordPress save hook
• Images served from the WordPress media library with Next's Image component

The client edits in WordPress like they always have. The visitors see a fast static Next.js site. Nobody wrote a custom CMS.

When to Graduate

Go to a dedicated headless CMS (Strapi, Sanity) when the content model needs relationships WordPress can't express, when there are multiple frontends pulling the same data, or when the editorial team is large enough to outgrow the WordPress admin. For single-site, single-team, blog-shaped content, WordPress wins on simplicity.

See the WordPress REST API handbook.