AI Model Configuration

If your product uses AI, you decide which models your tenants can reach. Backbuild ships a catalog of ready-to-use AI models, and you can add your own on top of it. For each SaaS package you publish, you curate that catalog down to the exact set of models your product offers, turning some on and leaving others off, so your tenants only ever see and use the models you intend to sell.

Pro AI model configuration is part of the SaaS Builder, included with the Backbuild Pro build-and-ship platform. See pricing.

How model availability works

Two kinds of model can appear in your product:

• Built-in models: the curated catalog of models Backbuild maintains and keeps up to date. You don’t configure the provider connection for these; you just decide whether each one is offered in your package.
• Your own models: models you register for your organization (for example, a provider or deployment you bring yourself). These behave the same way: each can be switched on or off per package.

By default, a package inherits the available models. The package-level configuration is an override layer: for each model you can explicitly enable it for the package or explicitly disable it. This lets you offer a deliberately small, supported set (a single fast model on an entry plan, a broader selection on a premium product) rather than exposing every model that happens to exist.

The model-availability view

When you list a package’s models you get one row per available model, each showing whether it is currently enabled for that package:

GET /v1/saas-packages/{packageId}/ai-models
Authorization: Bearer <token>

The list is paginated. Pass page and page_size (defaults to 50, capped at 200) as query parameters.

{
  "data": [
    {
      "model_id": "019d-aaaa...",
      "display_name": "Fast Chat",
      "model_string": "vendor/fast-chat-1",
      "is_system_model": true,
      "is_enabled_for_package": true
    },
    {
      "model_id": "019d-bbbb...",
      "display_name": "Deep Reasoning",
      "model_string": "vendor/deep-reason-1",
      "is_system_model": true,
      "is_enabled_for_package": false
    }
  ],
  "meta": { "page": 1, "page_size": 50, "total": 2, "total_pages": 1 }
}

Choosing the models your product offers

You set a package’s model availability by sending the toggles you want to change. Each override names exactly one model, either a built-in catalog model (by system_model_id) or one of your own (by org_model_id), and states whether it is enabled.

Toggle several models at once

The batch endpoint applies all of your changes atomically: either every toggle in the request is saved, or none is. Send between 1 and 200 overrides in a single call.

PUT /v1/saas-packages/{packageId}/ai-models
Authorization: Bearer <token>
Content-Type: application/json

{
  "overrides": [
    { "system_model_id": "019d-aaaa...", "is_enabled": true },
    { "system_model_id": "019d-bbbb...", "is_enabled": false },
    { "org_model_id":    "019d-cccc...", "is_enabled": true }
  ]
}

Each override must set exactly one of system_model_id or org_model_id. Setting both, or neither, is rejected with a validation error.

Toggle a single model

To change just one model, use the single-override endpoint. It accepts the same shape as one entry of the batch request.

PUT /v1/saas-packages/{packageId}/ai-models/override
Authorization: Bearer <token>
Content-Type: application/json

{
  "system_model_id": "019d-aaaa...",
  "is_enabled": false
}

Only the three fields above are accepted; any other key is rejected. The owning organization and package are taken from your session and the URL, not from the request body.

Per-plan model availability

The model toggles above scope a model to the whole package. To make a richer model available only on a higher tier, pair model availability with feature flags: gate the premium model behind a feature flag, map that flag to your upper plans, and have your application check the tenant’s effective feature set before offering the model. The package decides which models exist in your product; plan entitlements decide which tenants get to use each one.

A common pattern:

• Enable a single fast, inexpensive model for the package and leave it ungated, so every tenant can use it.
• Enable a more capable (and more expensive) model for the package, but gate it behind an advanced-ai feature flag mapped only to your business and enterprise plans.

Paying for AI: universal credits vs. bring-your-own-key

There are two ways the AI your product runs on can be paid for. You choose the model that fits how you want to package and price AI usage.

Universal credits

With universal credits, AI usage runs on Backbuild’s managed providers and is metered as credits. You don’t manage provider API keys at all. Instead, you decide how many credits each plan includes (and how overage is handled), and your tenants consume from that allotment as they use AI features. This is the simplest path: your tenants never see a provider, and AI cost is folded into the price of the plan you sell.

Bring-your-own-key (BYOK)

With bring-your-own-key, you (or, where you allow it, your tenant) supply the credentials for an AI or messaging provider, and usage is billed by that provider directly rather than metered as Backbuild credits. Provider credentials are configured through the integrations surface, stored encrypted, and never returned to the client or written to logs. See Integrations for how to connect and test a provider. BYOK suits products whose customers expect to run on their own AI accounts, or where you want AI cost to sit outside your plan pricing entirely.

The two approaches are not mutually exclusive across your catalog: a built-in model can be offered on credits while a registered model you connect runs on your own key. In all cases, model availability (which models appear at all) is controlled by the package toggles described above.

Permissions and scope

Reading and changing a package’s model configuration requires an authenticated session with rights to manage the package; the owning organization is always resolved from your session, and you can only configure packages your organization owns. The AI-model endpoints are available only when the SaaS Builder capability is enabled for your account.

API reference

All endpoints require an authenticated session. {packageId} is your SaaS package’s id. The owning organization is resolved from your session.

Override fields

Each override (whether in the batch array or the single-override body) sets exactly one of system_model_id (a built-in catalog model) or org_model_id (one of your own registered models), plus is_enabled (boolean). Supplying both ids, or neither, is a validation error.

Related

• Feature Flags & Entitlements: gate premium models behind plan tiers
• Integrations: connect a provider for bring-your-own-key usage
• Pricing Plans: include AI credits in the plans you sell

Frequently asked questions

Can I control which AI models my product offers?

Yes. As the publisher you choose which models your downstream tenants can access, rather than exposing everything by default.

Can model access differ by plan?

Yes. You can set model availability per plan, so a higher tier can unlock more capable models.

Who pays for the AI usage?

Either universal usage credits or a bring-your-own-key arrangement, as published on the pricing page.