Production case study · Carmen Cloud
Turning WordPress into the static front door for a world-class recognition platform
Carmen Cloud already had the difficult part: production APIs for vehicle, license-plate, transportation and cargo recognition. The relaunch added the customer-facing layer around those APIs—identity, workspaces, grounded documentation assistance, service workflows and a statically published WordPress frontend—with Gatey, AI-Kit, Flow and Static Publisher working together in production.
Status
Live in production
WP Suite products
4 working together
Editorial layer
WordPress retained
The recognition APIs did not need a new CMS. The customer experience around them did.
Starting point
A mature API platform and an established WordPress site
Carmen Cloud already had working recognition services and a WordPress-managed public presence. The product, however, had evolved beyond a simple account-and-one-key experience. Teams needed workspaces, role-aware access, multiple integration-specific API keys, clearer usage visibility and a better path from public content and documentation into a working implementation. Replacing the CMS would have created a migration project without improving any recognition engine.
WP Suite scope
Change the production responsibility of WordPress
WordPress and Elementor remained the authoring environment, but the public site was no longer required to serve every production request. Static Publisher handled repeatable publication, Gatey connected website-facing account journeys to the Carmen Cloud identity boundary, AI-Kit added grounded documentation assistance, and Flow turned the contact path into a backend-connected sales and support workflow.
Production outcome
One customer experience with clear ownership
The live carmencloud.com experience now demonstrates four WP Suite products operating together around Carmen Cloud’s own dashboard, workspaces, billing, API-key rules and recognition services. Editors keep their familiar CMS, visitors receive a statically delivered public site, and the interactive features continue through dedicated browser-side components and backends.
Static delivery should change how pages are served—not remove the interactive services that make the platform useful.
Gatey, AI-Kit and Flow continue through browser-side components and dedicated services after Static Publisher delivers the approved WordPress pages.
Two tracks, one release
Product evolution and website integration stayed separate.
The relaunch combined two connected workstreams without pretending they were the same system. Carmen Cloud continued to own the recognition product and customer application. WP Suite supplied the WordPress-facing service and delivery layer around them.
Carmen Cloud product evolution ├─ Workspaces and role-aware membership ├─ Multiple integration-specific API keys ├─ Key-level product permissions and usage visibility └─ Dashboard, subscriptions, credits, storage, hooks and recognition WP Suite integration layer ├─ Gatey → website-facing identity and account entry points ├─ AI-Kit → grounded chat and DocSearch over curated documentation ├─ Flow → multi-step sales and support journey └─ Static Publisher → repeatable static publication Both tracks → one browser experience around the existing APIs
Responsibility boundary WP Suite did not replace the Carmen Cloud dashboard, billing model, API-key logic or recognition services. Those remain product-owned capabilities. The case study covers the integration layer added around them.
WP Suite integration
Four products, each with a defined job
The project did not turn WP Suite into another monolith. Each component owns a narrow part of the customer experience and connects to the services around it.
- Gatey: identity at the website boundary — Gatey supplies the WordPress-side sign-in, account-aware navigation and profile entry points. Those components remain available after static publication because the browser connects to the configured Carmen Cloud identity layer instead of depending on a PHP page request. Carmen Cloud remains authoritative for workspace membership, roles, billing and application behavior.
- AI-Kit: grounded documentation assistance — AI-Kit adds DocSearch and chat to the developer experience. Its backend uses curated Carmen Cloud documentation and explicit product boundaries so that a plausible answer cannot casually mix vehicle plates, ADR markings, container codes, rail identifiers or other nearby recognition domains. The maintained documentation remains the source of truth; AI-Kit provides a more useful route into it.
- Flow: a structured route into the organization — The earlier generic contact path became a multi-step sales and support journey. Flow blocks collect context progressively and distinguish the visitor’s intent, while the Flow backend continues the submission into the configured service process. The frontend can therefore remain operational after static publication without sending the form through the public WordPress runtime.
- Static Publisher: WordPress authoring, static production — Editors continue to build pages in WordPress and Elementor. Static Publisher renders the approved site and publishes the production assets, separating public page delivery from the authoring environment. Browser-based identity, AI, workflow and Carmen Cloud application integrations remain live around those static pages.
Static page delivery did not make the platform less interactive.
Static WordPress
WordPress stayed. Its production responsibility changed.
The relaunch is not a headless rebuild and it did not discard the established editorial workflow. WordPress remains where pages and content are assembled. After approval, Static Publisher turns the rendered site into production assets that can be delivered independently of the WordPress runtime. Static, in this architecture, describes page delivery; it does not define the limits of the customer experience.
Identity journey
The public site and customer application meet at a clearer boundary.
A Carmen Cloud user does not stop being an application user while browsing a WordPress-managed page. Gatey gives the site account-aware entry points and connects the frontend to the configured identity layer. The journey can continue into the dashboard and protected APIs without creating a parallel WordPress identity model or moving Carmen Cloud’s workspace permissions into the CMS.
Developer experience
AI assistance respects the boundaries between recognition products.
A short question can use language shared by several recognition APIs while referring to very different identifiers and implementation details. AI-Kit was adapted around curated knowledge sources and explicit product separation. Ambiguous questions can be clarified, and DocSearch can lead developers to the right reference, tutorial or API definition instead of merely returning pages with similar words.
Documentation remains the source of truth. AI-Kit provides a more useful way into it.
AI-Kit uses curated Carmen Cloud documentation and explicit product boundaries to guide developers to the relevant reference without replacing it.
The relaunch added a service layer around the APIs, not another recognition layer.
Customer contact
The contact form became part of the service architecture.
One generic form is a poor entry point when one visitor needs API sales guidance and another needs technical help with an existing integration. The new multi-step Flow experience asks for information relevant to the selected path, reduces the undifferentiated form burden and gives the receiving team more useful context before follow-up.
Value around the APIs
Customers received clearer paths to understand and operate the platform.
The recognition engines remained the core product. Around them, the relaunch created a clearer path from public content to documentation, from documentation to an authenticated workspace, from a workspace to scoped integration credentials, and from a question to the appropriate sales or support process. WordPress handles content, while dedicated services handle identity, knowledge access, workflows and the customer application.
Production reference
The complete WP Suite pattern now runs on a real platform.
Carmen Cloud is not an isolated plugin demo. Gatey, AI-Kit, Flow and Static Publisher cooperate on one customer-facing production site while Carmen Cloud retains its own domain model and recognition infrastructure. Content, authentication UI, documentation prompts, contact journeys and recognition APIs can now evolve on their own schedules without being forced into one coupled website application.
The project did not change what the recognition engines recognize. It changed how customers reach, understand and operate the platform around them.
WP Suite added the website-facing service layer; Carmen Cloud still owns the dashboard, workspaces, billing, API-key rules and recognition services.
Architecture and ownership
One browser experience, with explicit responsibility boundaries
The page, identity, knowledge, workflow and recognition layers cooperate in the frontend, but each remains owned by the system designed for that responsibility.
WordPress + Elementor
└─ Content and layout
│
▼
Static Publisher
└─ Statically delivered production frontend
├─ Gatey → Carmen Cloud identity → dashboard and protected APIs
├─ AI-Kit → curated Carmen Cloud documentation
├─ Flow → sales and support backend process
└─ Carmen Cloud application → workspaces, billing, keys, usage and recognition
Recognition requests continue to Carmen Cloud APIs—not to WordPress.
Deployment Access boundary This case study proves that Gatey, AI-Kit, Flow and Static Publisher work together in production. It does not claim that every Carmen Cloud resource was installed through the current public WP Suite Deployment Access workflow.
Production outcome
What the integration now proves
The result is valuable because the components work together without erasing the boundaries that make the system operable.
- A real multi-product deployment — Four WP Suite products contribute to one production customer experience. Their cooperation is visible in the route from public content to identity, documentation, contact workflows and the Carmen Cloud application rather than in a collection of separate demonstration pages.
- WordPress without the usual runtime assumption — The editorial team keeps WordPress and Elementor, while the public site can be delivered statically. Authentication, AI assistance, forms and dashboard access remain available because those capabilities run through browser-side integrations and dedicated services.
- Carmen Cloud’s product boundaries remain intact — Workspaces, subscriptions, API keys, usage, hooks, dashboard behavior and recognition stay inside Carmen Cloud. The website integration improves how customers reach and understand the product without moving its domain logic into WordPress.
- The experience can evolve component by component — Editors can change content, the team can refine authentication entry points, documentation sources and contact journeys, and Carmen Cloud can continue developing its APIs. The components still form one experience, but they no longer have to share one release mechanism or runtime responsibility.
Case study details
Questions about the Carmen Cloud implementation
Did WP Suite replace Carmen Cloud’s recognition APIs?
No. The recognition APIs remain the core Carmen Cloud product. WP Suite added the website-facing identity, grounded documentation, workflow and static-delivery layer around them.
Is the Carmen Cloud site headless?
No. WordPress and Elementor remain the editorial environment. Static Publisher changes how approved pages are delivered in production; it does not replace the CMS with a separately authored frontend.
How can a static frontend still support sign-in, AI and forms?
The interactive capabilities run through browser-side components and dedicated services. Gatey connects to identity, AI-Kit reaches its configured backend and knowledge sources, Flow continues submissions into backend processing, and the Carmen Cloud dashboard calls its own protected APIs.
Was the complete environment deployed through Deployment Access?
This case study proves that Gatey, AI-Kit, Flow and Static Publisher work together in production. It does not claim that every Carmen Cloud resource was installed through the current public Deployment Access workflow.
Use the same separation of concerns
Keep WordPress as the CMS. Build the service layer around it.
Carmen Cloud shows the pattern in production: WordPress for editorial work, static assets for public delivery, and dedicated services for identity, grounded AI assistance, workflows and the customer’s own application logic.