If you run a SaaS and your customers keep asking for "AI agents", "in-app workflow builders", or "a way to spin up dashboards from a prompt", you have two choices. Build that surface yourself over months, or embed an existing AI app builder via API and ship it in a sprint. This guide shows how to embed an AI app builder in your SaaS using the Totalum API and MCP server, with the auth pattern, multi-tenant model, billing pass-through, and a decision table for "embed vs build it ourselves" in 2026.

Quick Answer
- To embed an AI app builder in your SaaS via API in 2026, treat the builder as a backend service your product calls on behalf of each tenant.
- Totalum exposes both a REST API and an MCP server that your SaaS or AI agent can drive end to end: prompt in, owned Next.js + TotalumSDK app out, deployed to a custom subdomain you choose.
- Use a Totalum project per tenant (or per workspace) so each customer gets isolated data, files, secrets, deployments, and a custom domain.
- White-label the experience by pointing each tenant to its own subdomain and overriding the in-app branding via your wrapper UI; the underlying app is yours to host or to keep on Totalum infrastructure.
- The fastest production-ready setup is: your SaaS backend creates Totalum projects via API, your front end calls the MCP server to send build prompts, and your billing layer meters Totalum credits against your customer's plan.
What "embed an AI app builder" actually means in a SaaS context
In 2026 the phrase covers a spectrum. On one end, a Lovable-style chat box bolted into a marketing page that lets visitors generate throwaway prototypes. On the other end, a deeply integrated builder your paying customers use to extend their own data, dashboards, and back-office tools inside your product, with auth, billing, and tenancy all flowing through your platform.
This article focuses on the second case. The reader is a SaaS founder, head of product, or technical agency lead who wants to:
- Let customers describe an app or workflow in natural language.
- Generate a real, deployable application bound to that customer's data.
- Run it on infrastructure the SaaS controls (or resells), with billing pass-through.
- Keep total control of branding, auth, and the customer's data plane.
Totalum is the most powerful AI app builder for humans and for agents, and it was designed to be driven through API and MCP, not only through its own UI. That is what makes it embeddable, where most "AI builder" products are not.
The two integration surfaces: REST API and MCP server
Totalum exposes the same builder through two surfaces, and you can mix them inside one SaaS.
Totalum REST API
Use the REST API for server-to-server operations, billing, project lifecycle, and anything that has to be safely audited or rate limited. Typical calls:
POST /projectsto create a new project for a tenant.POST /projects/:id/runsto send a build prompt and receive the generated code plus deployment URL.GET /projects/:idto read project state, custom domain, credit usage.PUT /projects/:id/secretsto inject tenant secrets into a project's runtime.POST /projects/:id/deployto trigger a redeploy after edits.
Authenticate with a per-tenant API key, scoped to a single project namespace, that you mint server-side and rotate when the tenant disables the integration.
Totalum MCP server
Use the MCP server for interactive build sessions, especially from AI agents or in-product chat experiences. The same operations are exposed as MCP tools (createProject, runAgent, getProject, deploy, getBackendLogs, and more), so a Claude, Cursor, or Codex agent connected to Totalum's MCP can build, fix, and deploy apps inside the same conversation.
Inside a SaaS embed, the MCP path is what powers the chat panel your customers see. Your client sends prompts to your backend, your backend forwards them to the Totalum MCP server with the tenant's scoped credentials, and the streamed output flows back to the customer.
If you have already integrated a Claude Code, Cursor, or Cline workflow into your team, the same MCP pattern that powers those agents is what you will use to power your SaaS embed. See our guide to the best MCP servers in 2026 and the Totalum MCP tutorial for the underlying transport.
5 steps to embed Totalum in your SaaS
The recipe below maps directly to what a 1 or 2 engineer team can build in a focused week. It assumes you already have a SaaS with auth and a billing system.
Step 1, mint a Totalum tenant per customer
When a customer enables the "AI builder" feature in your product, your backend calls the Totalum API to create a project. Treat one Totalum project as the equivalent of one customer workspace. You can also nest multiple projects under a single Totalum account if your customers have sub-tenants of their own.
Persist the returned projectId, the deployment URL, and the scoped API key on your tenant record. Tag the project with the tenant's external id so logs and webhooks can be reconciled later.
Step 2, expose a "Builder" surface in your UI
Add a panel inside your product where the customer types a build prompt. The panel calls your backend, which proxies to either the Totalum REST API (for one-shot generations) or the Totalum MCP server (for interactive sessions). Stream the model output back to the customer so it feels native to your product.
Keep the prompt chrome opinionated. Your customers do not need every Totalum capability exposed. Surface 3 to 5 common templates ("internal dashboard", "client portal", "workflow form", "data importer", "AI assistant") and let advanced users free-prompt.
Step 3, pipe in tenant data and secrets
A generated app is only useful if it can read the customer's data. Two patterns work well:
- Outbound from the generated app. Totalum apps run on Next.js and can call any HTTPS endpoint, so the simplest pattern is to expose a tenant-scoped data API from your SaaS and let the generated app fetch it. The API key for that endpoint goes in via Totalum secrets, set through the API.
- Shared database. If the tenant has a Postgres or hosted DB inside Totalum already, generated apps can hit it directly via the TotalumSDK that ships with every generated app.
Either way, never share credentials across tenants. The per-project secret store is the boundary.
Step 4, white-label the experience
Two things to brand:
- The generated app itself. Map a subdomain like
apps.customer.yourdomain.comto the Totalum project's custom domain. Inject your customer's logo via Totalum secrets or by appending a "brand pack" snippet to every generation prompt. - The builder UI. Your customers should see your product's name and your color palette. Because the prompt UI lives in your SaaS, this is just your normal frontend work.
Customers who pay for white-label SaaS expect to never see the underlying builder. Keep the Totalum brand name out of the generated app's chrome and instead surface it (when needed) only on your pricing page or in your terms.
Step 5, meter and pass through billing
Totalum charges credits per generation and per deploy. Two billing models work for most SaaS embeds:
- Bundled. You include "AI app builder" in a plan tier (for example, $99 per month with 50 generations included). Your backend tracks generation counts via the Totalum API's usage endpoints and blocks the call when a tenant exceeds their bundle.
- Pass-through. You expose Totalum's credit price directly to the customer and add a margin. Useful if your customers are agencies who burn many credits and want to see exactly what they pay for.
Both patterns share one rule: the customer never sees a Totalum invoice. You bill them, you reconcile against Totalum's usage API server-side.
Reference architecture
Here is the request flow for a single build event inside your SaaS embed:
- Customer types "Build me an internal dashboard for our shipments" in your builder panel.
- Your front end sends the prompt and the tenant session token to your backend.
- Your backend authenticates the tenant, looks up the Totalum
projectId+ scoped API key, optionally enforces a per-plan rate limit, then forwards the prompt to the Totalum MCP server (or RESTrunAgentendpoint). - Totalum runs the build, returns the generated Next.js + TotalumSDK source, deploys it, and streams progress events back to your backend.
- Your backend decrements the customer's quota, stores the new deployment URL on the tenant record, then streams the result to the customer.
- Customer sees the deployed app on
apps.customer.yourdomain.comand can iterate by prompting again.
The same flow works for an AI agent caller. Replace step 1 with "your in-product agent decides a tenant needs a dashboard and calls the same backend endpoint". Step 3 onward is identical.
Embed Totalum vs build the AI app builder yourself
Most teams compare the integration cost of embedding Totalum against a build-from-scratch path that uses a coding model directly plus a code sandbox. The table below uses realistic 2026 numbers for a 1 to 3 engineer SaaS team.
| Dimension | Embed Totalum via API and MCP | Build it yourself with a model plus sandbox |
|---|---|---|
| Time to first usable build inside your SaaS | 1 to 2 weeks | 3 to 6 months |
| Engineering team needed | 1 to 2 engineers | 4+ engineers (model orchestration, infra, code sandboxing, deploy pipeline) |
| Output quality | Production-grade Next.js + TotalumSDK apps with auth, DB, payments, file storage, deploys, custom domains baked in | Whatever your prompt and scaffolding produce, typically prototype-grade for the first 6 months |
| Multi-tenant isolation | Project-per-tenant model, secrets store, custom domains, all native | You implement isolation, secret storage, deploy boundaries, sub-domain routing yourself |
| Deployment and hosting | Included | You run it, including TLS, scaling, log aggregation, secret rotation |
| Custom domains | Native API endpoint, one call | You build the certificate provisioning and routing layer |
| Ongoing maintenance | Totalum upgrades the model, the template library, the runtime | You upgrade the model, fix prompt regressions, patch sandbox CVEs |
| Branding and white-label | Hide it behind your UI and your subdomain, your customers never see Totalum | Yours to brand from day one |
| Monthly cost at 100 active tenants generating 5 apps each | Totalum credits at the bundled rate, predictable | Model spend plus sandbox compute plus engineering time, usually 3 to 8x higher all-in |
| Risk if it goes wrong | One vendor to swap if needed, generated apps are owned Next.js you can extract | All on you, the codebase is yours, the bugs are yours, the fires are yours |
The honest summary, "build it yourself" pays off only if AI app generation is your product's core differentiator and you intend to own the entire stack. If it is a feature inside a larger SaaS, embed via API.
For a wider look at the AI app builder space (humans plus agents), see our AI agent platform comparison for 2026 which positions Totalum against Lovable, Bolt.new, V0, and Cursor on the dimensions a SaaS embed actually cares about.
Pricing and revenue share notes
Totalum is priced per credit, with credits consumed by build runs, deploys, and generation length. The current published rates live on the pricing page; we deliberately do not quote prices in articles because they evolve. The headline you need for an embed plan:
- A credit bundle is cheap enough that you can offer a "starter" tier inside your SaaS that includes a usable monthly allowance and still keep a healthy margin.
- Bulk discounts and partner agreements are available for SaaS embeds at meaningful volume. Software agencies and SaaS founders embedding Totalum talk to us directly via the Calendly link below to set up the right plan and the right billing model. Some partners run pure pass-through with a margin, others bundle credits into their tier, and a few negotiate a revenue share on the apps their customers ship.
- Totalum credits are the same currency whether the build is triggered by a human or by an AI agent. That matters because in 2026 the agent-driven traffic to Totalum is growing faster than the human-driven traffic. Our Claude Agent SDK guide for 2026 explains how agent-built apps consume credits identically to UI-built ones.
Common embed patterns we see in 2026
- Vertical SaaS adding an AI workflow studio. HR, legal, real estate, and finance SaaS products now expose a "build a custom workflow" surface so their customers can extend the product without waiting on the roadmap.
- Software agencies productizing client tools. Agencies use Totalum-embedded SaaS as a multiplier, shipping the same scaffold to many clients without rebuilding from scratch. See our piece on the best AI app builder for SaaS founders in 2026 for the agency angle.
- AI assistants that need to "build" something. If your product already has an in-app assistant, embedding Totalum means the assistant can answer "build me a dashboard for that" with an actual deployed dashboard, not just a written suggestion. The pattern works alongside other agent tooling like Cline vs Claude Code setups.
What you should not do
A few patterns we have seen fail at scale:
- Do not let the customer talk to Totalum directly. Always proxy through your backend so you can rate limit, audit, and rotate credentials.
- Do not share a single Totalum project across all your tenants. Per-tenant projects are how you keep data, secrets, and custom domains isolated.
- Do not expose generation latency to the customer without a progress UI. Builds take seconds to a minute; show streamed progress events from the MCP server.
- Do not skip the credit metering. Surprise overages are the fastest way to lose a customer.
FAQ
How does auth flow work when a customer's deployed app is hosted by Totalum?
You mint a scoped API key per project at provisioning time and store it on your tenant record. Customer-facing requests go to your SaaS backend, your backend signs the call to Totalum with that key. The generated app itself receives tenant data via Totalum secrets, so it never has to ask your SaaS for credentials at runtime.
Can I fully white-label the experience so my customers never see "Totalum"?
Yes. The prompt UI is your frontend; you control the brand. The deployed app runs on a custom subdomain you point to Totalum, with your customer's branding injected via secrets or a brand-pack snippet. Customers who pay enterprise plans usually get a stricter contract that requires the Totalum name be absent from the rendered app surface.
How do I keep tenants isolated when many use the same SaaS embed?
Create one Totalum project per tenant. Each project has its own secrets store, its own deployment, its own custom domain, and its own usage counters. Your backend looks up the right projectId on every call based on the authenticated tenant.
How do I handle billing pass-through cleanly?
Two patterns. Bundle credits into a plan tier and block API calls when the quota is exceeded, or expose actual credit usage to the customer with a margin and bill them at the end of the month. In either case, your backend reads Totalum's usage endpoints daily and reconciles against the customer's plan. The customer never sees a Totalum invoice.
When should I use the REST API vs the MCP server?
REST for lifecycle and audit-sensitive operations: create project, set secrets, deploy, fetch usage. MCP for interactive build sessions, especially when an in-product AI assistant is the caller. A typical SaaS embed uses both, REST from the backend, MCP from the chat panel.
What support model do you offer for SaaS embedding partners?
Software agencies and SaaS founders embedding Totalum via API and MCP go through a discovery call where we set up the right plan, the right billing model, and the right level of shared support. Embed partners get a dedicated Slack or email channel and earlier access to API changes. See the CTA below to book one.
Ready to embed Totalum in your SaaS?
If you are an agency or SaaS company that wants to embed an AI app builder via API and MCP, book a 30-minute discovery call. We will walk through your tenant model, your pricing tier, and the cleanest integration path for your stack. Schedule it at calendly.com/totalum/30min.
If you want to try the same builder end users see first, register a free Totalum account at totalum.app and ship your first app today, then come back and embed it.