Hybrid Headless CMS: Editing Experience and API Flexibility

Q: Which front-end frameworks can we use?

Blazor, Bootstrap, React, Vue, Angular and others. The content repository is not tied to a rendering layer, so the framework choice is yours and can change later without re-platforming.

Q: What happens when we add a new channel, like a mobile app?

It is a configuration change rather than a migration project. The same content repository already serves your website, your app and any partner or AI system that consumes the API all from one platform you operate.

Q: Is the API REST, and is it documented?

Yes. BWA exposes documented RESTful services with auto-discovered endpoints, plus webhook support for anything not covered by a native connector.

Q: Do we have to commit to headless up front?

No. Headless is a delivery mode, not a separate product or a separate installation. The same content core can serve server-rendered pages today and an API-driven front end later, without moving content between systems.

Q: Can AI systems and partners consume our content directly?

Yes, that is the point of one repository behind many front ends. The same content that serves your website and your app is available to any partner or AI system that consumes the API, over a self-documenting REST surface.

Q: Does BWA support MCP?

Yes. BWA runs a Model Context Protocol server, so an MCP client can ask the site questions about its content and where you allow it, make governed changes to records. The endpoint is authenticated, and any writes run under the domain's Agent Action policy rather than having free rein.

What your team hands over

What comes back

Its own admin screen
Settings your editors control
Permissions and roles applied

Held for sign-off

The problem

A signed-off design still isn't a shipped feature.

The design gets approved, and then somebody rebuilds it by hand in whatever framework the platform runs on. Weeks per screen, a queue behind every revision, and what finally ships is never quite what was agreed.

The design is only a reference

A developer recreates it from scratch in the platform's own framework. Every change after launch is two jobs, update the design, then pay to have it rebuilt again.

The design becomes the module

The same file arrives as a running module with its own admin screen, settings and permissions, held at a review until someone on your team signs it off.

Headless

Headless, without giving up the CMS.

Most headless platforms make you trade the editing experience for the API. You don’t have to pick.

Your editors keep a real CMS

Go headless on the front end and your team still gets the admin, the preview and the page they’re used to, not a JSON form and a hope. The usual cost of going headless is the part nobody warns you about.

The API isn’t a tier you buy

Every entity is readable and writable over REST, under the same permission rules the admin uses. It’s how the platform talks to itself, so nothing is held back for a higher plan.

Any front end, and whatever’s next

React, Vue, Angular, Svelte, a mobile app, or server-rendered pages from the same content. Plus a built-in MCP server and an NLWeb endpoint, so AI agents can read it directly.

Draft and publish are in the model

Content carries version and publish state natively, so a draft, a scheduled release and a rollback are properties of the record, not a workflow bolted on beside it.

It tells you when things change

Webhooks fire on publish, so a static front end rebuilds itself. No polling loop, no stale pages waiting on a cron job.

Empower Your Development Team with Advantage

Step 1

Design & Develop

Craft stunning digital experiences using your preferred frameworks and languages.

Step 2

Integrate & Deploy

Seamlessly connect with existing systems and deploy with confidence across multiple channels.

Step 3

Manage & Scale

Monitor, manage, and scale your digital products effortlessly with our advanced tools and robust infrastructure.

How it works.

From content to any front end, in four steps.

Ship content to websites, apps, and third-party systems from a single source of truth, without managing separate platforms for each channel.

Content lives in one repository

Pages, products, courses, and member data are created and managed once, through the same admin tools regardless of how they'll be delivered.

Endpoints register automatically

WebAPI controllers self-register as they're deployed, and Swagger/OpenAPI documentation generates directly from the live controllers.

Any front end consumes the API

React, a mobile app, or a partner system calls the REST endpoints directly, no separate headless CMS or sync process required.

Updates propagate through existing tools

Content managers publish through the same visual page builder and admin screens they already use, changes are reflected everywhere the API is consumed.

example-request.http

# Request
GET /api/v1/content/{contentType}
Authorization: Bearer <token>
Accept: application/json

# Response  200 OK
{
  "items": [
    {
      "id":       4821,
      "title":    "Getting Started Guide",
      "domainId": 12,
      "page": {
        "slug":      "getting-started",
        "published": true
      }
    },
    {
      "id":       4822,
      "title":    "API Reference",
      "domainId": 12,
      "page": {
        "slug":      "api-reference",
        "published": true
      }
    }
  ]
}

By role

Headless, from where you sit.

Headless isn't a rebuild. It's a delivery mode already built into the platform you run today, the same content, served to whatever needs it.

Business IT Teams Developers

Reach new channels without a rebuild.

Launch a new app or portal on the content you already hold, no re-platforming project.
One team publishes once, and every touchpoint picks it up, no duplicate updates per channel.
One platform to license and support, instead of a separate headless product alongside your site.

One source, every channel

Your content
repository

Public website

Mobile or member app

Partner and AI systems

Governed, not just flexible.

Each domain is isolated at the data layer, so one tenant's content can't be read from another.
Built on .NET with enterprise security controls already in place encryption in transit and at rest, and hardened session handling.
Runs on Azure or your own infrastructure, no extra vendor or hosting footprint to secure and audit.

What is enforced, and where

Tenant and domain isolationData layer

Roles, permissions and session policyPlatform

Release sign-off before anything goes liveYour team

A real API surface, documented as you build.

REST and GraphQL endpoints serve structured content to any client, framework or device.
The content model is the schema, nothing separate to configure, and it stays in step as the model changes.
Build in React, Razor or anything that speaks REST, with outbound webhooks for event-driven work.

The surface you get

GET/api/content/{type}

GET/api/content/{type}/{id}

POST/api/graphql

HOOKoutbound on publish, update, delete

Which front-end frameworks can we use?

What happens when we add a new channel, like a mobile app?

Is the API REST, and is it documented?

Do we have to commit to headless up front?

Can AI systems and partners consume our content directly?

Does BWA support MCP?

What is NLWeb, and why would we turn it on?

NLWeb is Microsoft's open protocol for making a site readable by AI agents. BWA implements its /ask endpoint: an agent sends a plain-English question and gets back Schema.org-typed JSON rather than a page of HTML it has to scrape. Every NLWeb instance is also an MCP server, so the two share the same underlying data.

Is the NLWeb endpoint safe to leave open?

It is anonymous by design, that is what makes a site agent-readable and the safety comes from what it is allowed to see rather than from who is asking. It answers only from content the domain has explicitly published: entities registered as public-read in that domain's API profile, plus published pages. Nothing outside that set is reachable through it.

Reliability of Traditional Systems With The Flexibility Of Headless CMS

A signed-off design still isn't a shipped feature.

The design is only a reference

The design becomes the module