Documentation

The assistant answers questions exclusively from the stored knowledge base and identifies the passages it relies on. If it finds nothing, it says so rather than guessing. Every answer is labelled as machine-generated.

The tenant’s monthly language-model allowance. Before each answer, the system checks that credit remains; usage is charged after the run at the actual amount. When the allowance is exhausted, the chat stops without automatic extra charges. Widget messages also have a separate monthly allowance. End customers use their agency’s shared pool.

How many separate knowledge bases a tenant may maintain. Each has its own vector collection so that different end customers’ content cannot mix — separation is a storage boundary, not a query filter.

The upper limit for stored source documents per tenant. Usage is counted across all knowledge bases so that adding bases cannot bypass the limit; an upload, sync or push that would exceed it is rejected before the file is written; a sync then stops and deletes nothing.

The module that enables automatic content sources. Without this feature, all connectors remain disabled, even if individual connectors are listed in a package — the module is the parent switch, and its children are disabled without it.

Reads the end customer’s website and keeps the knowledge base up to date from it. The chat can then answer questions about services, prices and opening hours using the same source that visitors see on the site.

Connects a Shopware store as a source, including live updates via webhooks. Product data and descriptions enter the knowledge base without anyone having to maintain them manually.

The same for WooCommerce stores: catalog data is imported and kept current via webhooks. Intended for end customers whose product range changes frequently but whose chat still needs to answer correctly.

Imports Zendesk help-center articles into the knowledge base. The chat then answers the same questions as the support team, using the same wording and without a second place to maintain content.

An open entry point for content from systems without a ready-made connector. Content is pushed in from outside rather than fetched — intended for ERP systems, intranets and custom applications.

The monthly upper limit on the number of pages read across all connectors. Every fetched page uses the allowance; when it is empty, the run stops rather than continuing silently.

How many embeddable chat widgets a tenant may operate. Each widget is linked to a knowledge base and placed on the end customer’s website with a code snippet — one widget per end customer is the normal setup.

The monthly message allowance for all of a tenant’s widgets. It is served from the agency’s shared pool so that one high-traffic end customer cannot silently drain the allowance for everyone else.

The landing page module: assemble pages from blocks, edit drafts and publish. Publishing writes a new version instead of overwriting the old one — what was once public remains traceable.

How many pages a tenant may create. The limit is checked atomically during creation so that two simultaneous attempts cannot jointly exceed it. The overview shows the amount used.

Gives end customers permission to edit and publish their own page instead of sending every change through the agency. Without this feature, they can view their page but cannot change it.

Storage limit for landing page images and files, calculated across all pages belonging to an owner. Uploads check the total before writing, not just the individual file — otherwise the limit could be bypassed in small steps.

Creates a complete page draft from a short brief — industry, offer, audience and tone. The result is a draft and does not go online by itself; publishing remains a deliberate action.

The monthly allowance for AI page drafts. Credit is consumed before the model call and refunded on failure so that an interrupted run does not cost anyone credit.

How many end customers an agency may manage beneath it. Each sub-tenant has its own data, users and knowledge bases; the limit is checked atomically during creation.

Allows the agency to package its own feature scope for end customers and set its own prices. It cannot pass on what it does not have — limits are capped at its own allowance.

Runs administration and landing pages on the agency’s own domain instead of a Brixovo address. The domain is claimed, verified and can be detached again without losing content.

Legacy metadata from the former plan logic. Branding itself is now available to all tenants; this key no longer enables anything at runtime and is retained only to keep old plan or override data historically readable.

Also only legacy metadata. Visible branding is no longer controlled by this feature key; the interface reads the tenant’s saved brand values directly. The entry remains in the catalog solely for existing legacy data.