Managed Intelligence as a Service

This is where C4X differs most from a typical MSP. We build custom automation and AI-driven tooling in-house, running on infrastructure we own, rather than reselling a vendor's off-the-shelf automation add-on. Recent examples include a purpose-built log-routing system solving a real gap in how two security tools integrate, and a self-hosted AI request router handling model-specific traffic that a vendor's default setup could not.

We call this Managed Intelligence rather than just automation because the value is in what runs on top of the automation: models and logic tuned to a client's actual environment, monitored and improved the same way we operate everything else, not a one-off script left to rot.

See the technical notes below for sanitised write-ups of real automation and AI systems C4X has built and shipped.

From the Engineering Team

Technical Notes

Sanitised write-ups of real automation and AI systems C4X has built and shipped — concrete examples of what Managed Intelligence looks like in production, not a features list.

Fixing a Multi-Tenant Gap Between NinjaOne and Huntress

A Cloudflare Worker that correctly attributes endpoint logs across client organisations where the native integration could not.

Huntress’s native integration with NinjaOne cannot map multiple NinjaOne client organisations to separate Huntress organisations. In a multi-tenant MSP setup, that means every client’s endpoint logs land in one shared bucket, with no clean way to separate one client’s alerts from another’s.

What we built

C4X built a Cloudflare Worker that sits between NinjaOne and Huntress. NinjaOne is configured to hit a single webhook URL; the Worker performs a KV lookup to match the originating organisation to the correct Huntress API token, then forwards the log with the correct attribution attached.

Why it matters

Onboarding a new client now takes one KV entry, with no changes required to NinjaOne or Huntress configuration, and no risk of one client’s alerts landing in another’s feed. It is a small piece of infrastructure that solves a real multi-tenancy gap most MSPs running the same two tools simply live with.

This work has previously been shared publicly on LinkedIn and open-sourced in earlier form.

Routing 3CX AI Requests to the Right Azure OpenAI Deployment

A self-hosted proxy that solves a vendor assumption mismatch between 3CX and Azure OpenAI deployments.

3CX’s AI features (transcription, analytics, realtime) call an OpenAI-compatible API, but send different model strings per feature from a single API key rather than being scoped to one model per key. That assumption does not match how Azure OpenAI deployments actually work, where each deployment is tied to a specific model.

What we built

C4X built a self-hosted proxy that routes each incoming request to the correct Azure OpenAI deployment based on the incoming key, passing the requested model straight through as the Azure deployment name. An admin panel manages key mappings and logs, giving full visibility into what is being routed where.

Why it matters

This solves a real integration mismatch between a vendor’s fixed assumption and how self-hosted AI infrastructure actually needs to route requests, without waiting on the vendor to fix it or compromising on which AI backend handles the traffic.

Rebuilding a Multi-Tenant Client Data API: From n8n to Cloudflare Worker

Why we moved a live, multi-tenant Microsoft Graph integration off a workflow tool and onto a properly scoped, edge-native API.

A workflow pulling Microsoft Graph data (17 distinct actions) across every client tenant used to run in n8n. That worked while it was small, but a workflow tool built for orchestration is not built to be a properly scoped, audited API handling live client data at scale.

What we built

C4X rebuilt the integration as a dedicated Cloudflare Worker. Instead of one over-privileged application registration, the new API uses three separate Entra app registrations with individualised, non-combinable permissions, so no single credential can reach more than its intended scope. An IP allowlist is checked before API key authentication, and a self-documenting Swagger-style docs UI is served at the root for anyone who needs to integrate against it.

Why it matters

Moving a multi-tenant integration handling live client data off a general-purpose workflow tool and onto a properly scoped, edge-native API was the right call for something operating at this scale and sensitivity. It is a migration story as much as a build story: recognising when a tool that got you started is no longer the right tool for what the integration has become.