If you are building with Lovable, Bolt.new, v0, or Replit Agent, the frontend question gets solved first. You can generate screens, flows, auth, and deployment faster than ever.
The backend question shows up a little later.
Once marketing wants to update homepage sections, product wants reusable launch content, or your team needs app copy in more than one place, you need a real content API. That is where many teams hit the next decision: should your headless CMS expose GraphQL or JSON:API?
This matters more in April 2026 than it did a year ago. On February 3, 2026, Vercel positioned the new v0 around production apps and agents. On February 26, 2026, Bolt launched Connectors built on remote MCP servers. Lovable's current docs also lean hard into APIs, integrations, and personal MCP connectors. AI builders are moving beyond prototypes. That means your content layer needs to be boring, stable, and easy to consume at runtime.
The short version is simple:
- Use GraphQL when your frontend needs flexible queries, fewer round trips, and cleaner component-driven data fetching.
- Use JSON:API when you want a standards-based REST shape, predictable resource URLs, and easier generic integrations.
- If your CMS supports both, you do not have to force one answer across every use case.
For many teams, that last option is the best one.
Why AI-built apps make this decision more important
In a traditional project, frontend and backend architecture usually get discussed together. In an AI-built app, they often do not.
The builder gives you a UI quickly, maybe a database, maybe auth, maybe some generated server routes. That speed is useful, but it creates a common mess:
- content hardcoded into React components
- landing page sections stored in JSON files inside the repo
- marketing copy mixed with product logic
- no reusable model for FAQs, testimonials, pricing blocks, or campaign pages
That is when teams start searching for a lovable backend, a bolt.new CMS, or a headless CMS for AI apps.
At that point, the API choice is not abstract. It affects:
- how fast your generated frontend can fetch content
- how easy it is to type and validate responses
- how much overfetching or underfetching you deal with
- whether non-developers can manage content without editing code
The API is not the whole CMS decision, but it shapes the developer experience more than people expect.
What GraphQL is good at
GraphQL is strongest when your frontend wants exactly the data it needs and nothing more.
That fits AI-built frontends well because generated apps often have component trees that want narrowly scoped data. A hero needs one set of fields. A pricing block needs another. A related-content section needs a third. GraphQL lets you compose those requests without making the frontend juggle multiple REST endpoints.
That is especially useful when:
- your app has dynamic page sections
- you need nested relationships in one request
- you want typed queries in TypeScript
- your frontend changes quickly as prompts and components evolve
Example:
const query = `
query LandingPage($path: String!) {
pageByPath(path: $path) {
title
seoTitle
hero {
headline
subhead
ctaText
}
sections {
__typename
... on FeatureGrid {
title
items {
title
description
}
}
... on TestimonialStrip {
title
testimonials {
quote
author
}
}
}
}
}
`
For a React or Next.js frontend, that shape is hard to beat. The component can ask for what it renders, and the CMS can return it in one response.
The trade-offs are real, though:
- caching can be less straightforward than REST
- query design needs discipline
- generic third-party tools are more likely to support REST than GraphQL first
If your team does not have a clean content model, GraphQL can also expose that mess faster instead of fixing it.
What JSON:API is good at
JSON:API is strongest when you want a predictable, standard resource model that works well across tooling.
For many teams, especially those integrating more than one consumer, that matters. A web app, a lightweight automation, and an internal admin tool can all work against a resource-oriented API without needing custom query design.
JSON:API tends to fit well when:
- your team prefers REST conventions
- you want stable URLs for resources and collections
- you are building generic integrations or automation jobs
- you want simpler debugging in the browser and logs
Example:
export async function getArticle(slug: string) {
const url =
`${process.env.CMS_URL}/jsonapi/node/article` +
`?filter[field_slug]=${slug}` +
`&include=field_author,field_cover_image`
const res = await fetch(url, {
headers: {
Authorization: `Bearer ${process.env.CMS_TOKEN!}`,
Accept: 'application/vnd.api+json',
},
next: { revalidate: 300 },
})
if (!res.ok) throw new Error('Failed to load article')
return res.json()
}
That is not as elegant for highly customized page composition, but it is very good for consistent resource access.
The trade-offs:
- complex pages can require more careful include and filter handling
- frontend developers may need to normalize relationships
- you may fetch more than a single component actually needs
Still, JSON:API is often the safer default when you want an API that many systems can understand without much explanation.
Which one is better for Lovable, Bolt.new, and v0?
The honest answer is: it depends on what part of the app you are feeding.
For generated frontends, GraphQL usually wins. AI builders produce UI quickly, and those UIs often benefit from fetching exactly the fields each screen needs. That keeps the integration layer cleaner as the app changes.
For operational integrations, JSON:API often wins. If you are syncing content, building automations, or exposing resources to more than one consumer, the standard REST model is easier to reason about.
A practical split looks like this:
- use GraphQL for page rendering in React and Next.js
- use JSON:API for scripts, automation, imports, and generic resource access
- use MCP for setup and editorial tooling, not as the main runtime delivery layer
That last point matters. MCP is becoming standard in builder workflows, but your live app still needs a normal API surface. Build-time agent tools and runtime content delivery are related, not identical.
Why Drupal is still a strong option here
This is one reason Drupal headless CMS setups remain relevant in 2026.
Drupal gives you mature content modeling, revisions, workflows, permissions, and structured media handling. Then you can choose the delivery style that fits the consumer:
- GraphQL for flexible frontend queries
- JSON:API for resource-oriented integrations
That is a strong fit for AI-built apps because the frontend moves fast while the content layer needs to stay governed.
It also aligns with where the ecosystem is moving. The MCP roadmap published on March 9, 2026 emphasized scalability and enterprise readiness for remote servers. Meanwhile, AI builders are increasingly good at generating UI and workflows, but they still do not replace editorial systems. A decoupled Drupal backend lets you keep those responsibilities separate.
This is also where Decoupled.io fits naturally. It is a managed headless Drupal platform, so teams can use a visual editor, AI content generation, and MCP tooling without taking on all the usual self-hosted Drupal overhead. More importantly, it does not force you into one API style. If your React frontend wants GraphQL and your integration job wants JSON:API, that is a reasonable architecture.
If you want to see how that looks in practice, the relevant docs are GraphQL, JSON:API, and AI builder integration.
A simple decision framework
If you need one rule of thumb, use this:
- Choose GraphQL if the main problem is frontend flexibility.
- Choose JSON:API if the main problem is integration consistency.
- Choose a CMS that supports both if you know your app will have marketers, developers, automations, and AI agents all touching content in different ways.
That is usually the real answer for production teams. One interface is rarely enough forever.
The mistake is not picking the "wrong" API first. The mistake is choosing a CMS that locks you into only one delivery pattern while your app surface area keeps expanding.
CTA
If you are connecting Lovable, Bolt.new, v0, or a custom React frontend to a content backend, start by deciding which consumers need flexibility and which need standardization.
Then review the GraphQL docs, JSON:API docs, and Getting Started. Decoupled.io is strongest when you use it as a managed content layer behind AI-built frontends: visual editing for marketers, structured APIs for developers, and MCP tools where agent workflows actually help.