AI in your app

The table below is the plan of this guide. Read it first: it prevents three quarters of the bad choices.

One sentence to hold on to the distinction: the RAG chatbot knows what you published, the ChatGPT extension knows what the model learned. The first one can't answer on a subject you've never covered. The second one will answer anyway, and that's sometimes exactly what you don't want.

The two can coexist in the same app. A general conversation assistant on the home screen and a documentary chatbot in the archive section aren't competing.

RAG stands for retrieval-augmented generation. The principle fits in one sentence: before answering, the assistant goes and finds the relevant passages in your content, and writes its answer from those passages.

That's the difference between an assistant that knows your subject and an assistant that knows yours. For a ten-year article archive, a travel guide, an internal manual or a base of frequently asked questions, it's the only form that holds up: the answers stay within the boundaries of what you've written, and they age at the same rate.

The chatbot is an extension before it is a section, and the order matters. Everything starts from the RAG Chatbot entry in the main menu, at the first level between Notification and Statistics: that's where you add the extension, and only once it has been added does the section become available in your app. Looking for it in the list of sections before going through there means not finding it.

Once it's in place, it behaves like any other section: it takes its place in your menu, it counts towards your 120 sections, and it picks up your app's colors and typography.

Its settings open from the same menu entry, on a screen with four tabs: settings, design, source sections, and reports.

This is the setting that decides the quality of your chatbot, and it's also the one people rush.

The Sections tab lists yours, filed by content type: your articles, your events, your locations. You tick the ones that should feed the knowledge base, and you can go down to category level: the whole Articles section, or only the Practical category.

Everything you publish in those sections afterwards enters it automatically. There's no update button to remember, no export to redo: your knowledge base follows what you publish.

One last setting completes the picture: a cap on how many items are kept from each selected source, from the most recent backwards. Raising it gives the assistant more material and uses more credits. A publisher posting every day and a stable travel guide don't need the same value.

Two models are set separately, and they don't do the same job.

The generation model is the one that writes the answer. The list runs from the most recent models down to their Mini and Nano variants, faster and more frugal. It includes OpenAI models and Mistral models, which lets you stay on European infrastructure when that matters to you.

The indexing model is the one that turns your content into something search can work with. Its large version handles long, nuanced texts better; its economical version is faster and uses less.

The practical rule: start with an economical variant, measure the quality of the answers on your real questions, then move up if you aren't there. Doing it the other way round costs money for nothing.

A writing tone field lets you describe how the assistant addresses your readers: the level of formality, the style. This field isn't there to add knowledge, it's there to set the voice.

It carries the most useful instruction on the whole screen, though: the one saying what to answer when the answer isn't in your content. Without it, an assistant often prefers to improvise rather than admit it. Write it explicitly: tell it to say it doesn't know and to point to your contact page. One sentence, and your chatbot stops inventing.

Two toggles decide what appears beneath the answers. Interactive source cards show the article, event or location the answer was built from, and the reader opens it in one move. A second toggle adds a copy button on each message in the conversation.

Look at that answer: it isn't just correct, it says where it comes from. Every recipe quoted carries its link to the article, and the row of cards below the conversation takes the reader back into the content. That's the visible difference between an assistant drawing on you and an assistant talking from memory.

Switch the source cards on. They do three things at once: they prove the answer really comes from you, they bring the reader back into your content instead of leaving them in the conversation, and they give you a way to check your chatbot at a glance.

An access restriction option closes the chatbot to passing visitors and reserves it for people who are logged in or subscribed. It leans on one of the platform's two access families, the in-app membership extension or the Authentication extension, so one of the two has to be active in your app.

Those two families don't stack: that's the fork described in "Building a community with your app", and it's decided beforehand, not afterwards. If your app lives on an in-app membership, that's what the restriction goes through.

It's a good candidate for reserved content. An assistant that knows ten years of your archive has a value a reader grasps immediately, which is rarely true of one more article.

The RAG chatbot is an extension, and its listing shows the price that applies to your app. It includes a volume of credits, renewed each month, and a counter at the top of the screen shows the remaining balance along with the next renewal date. The volume included is on that same listing.

Two things consume those credits, and not in the same proportions. Indexing your content costs little and happens once, then on each publication. Your users' questions cost the rest, and their consumption depends on the model chosen and on the complexity of the question. In other words, your bill follows your audience: that's good news, provided you saw it coming.

The other kind of assistant doesn't read your content. It plugs an instance of ChatGPT into your app, and you give it a role.

Like every extension, its listing shows the price that applies to your app, and it works on both product lines, content apps as well as e-commerce apps.

Like the RAG chatbot, it's an extension before it's a section, and the same order applies: you switch it on first in Extensions Store › All extensions, and the section only appears in the list of types once that's done. You'll then find the status of all your extensions in Extensions Store › Management.

Its settings open from the section's menu, through the entry that configures the assistant. Its screen has only two tabs, settings and design, where the RAG chatbot has four. That's the difference in nature, visible to the naked eye.

The first difference is right there, and it isn't trivial. An OpenAI access block asks you for a secret API key, which you create on your OpenAI account. The commercial relationship stays between you and OpenAI: GoodBarber charges nothing on the conversations and takes nothing on the way through.

What that means in practice: you open an account at OpenAI, you put a payment method on it, and you watch consumption from their dashboard, not from your back office. Some recent models also require your organization to be verified at OpenAI, which the screen flags.

Three fields only, and the third one carries everything else. You enter the assistant's name, you choose a generation model from a list running from the most recent to the most economical, then you write the system message.

That text is the only thing separating your assistant from an ordinary ChatGPT. It describes its role, its tone, and above all the range of subjects it agrees to handle. An assistant that hasn't been told what it talks about will talk about everything, including things you don't want in your app.

Write it in two parts. First the role, put simply: who it is, who it's talking to, on what subject. Then the closure, just as important: what it should answer when the question falls outside the subject. That second half is the one people forget, and it's what keeps the assistant in its lane.

Like the RAG chatbot, the ChatGPT extension can be reserved for your logged-in users, through the same restriction option, and its appearance is set in the design tab.

It follows directly from how it works: this assistant doesn't know your content. It doesn't know what you published yesterday, or your opening hours, or your prices, or the name of your new collection. If a user asks, it will answer all the same, with whatever the model believes it knows.

The system message reduces that risk, it doesn't remove it. So keep this extension for uses where the answer doesn't have to be yours: an assistant that advises, that rephrases, that walks someone through their first steps. As soon as the answer has to be exact and verifiable, the RAG chatbot is what you need.

The question is settled on a single line: does the answer have to come from you?

Three examples to anchor the rule.

A school. Paraigua publishes its calendars, its rules and its circulars. The same questions come back every year, on the same dates, and each one already has its answer written somewhere. This is the textbook RAG case: the material exists, it's just badly reachable.

A travel guide. Portland describes places, events, routes. A visitor asking "what's open on Sunday morning near the harbor" is asking something the content answers, but that no menu lets them phrase. RAG again.

A beauty salon. Freyja Spa has no body of documents, but it does have clients hesitating between two treatments. An assistant framed by a system message, asking two or three questions and steering towards the right service, is useful without needing to know the catalog by heart. The ChatGPT extension is enough, and it costs nothing more.

The RAG chatbot only exists on content apps. An e-commerce app can't switch it on today. On that line, the ChatGPT extension is still available.

A chatbot only answers well if your content answers. This is the limit most often discovered too late. An assistant plugged into thirty vague articles produces thirty vague answers, and it makes visible a content problem that went unnoticed as long as nobody asked the question directly. Before switching it on, reread what you publish and ask yourself whether a reader would find their answer there. If not, it's the content that needs work, not the model.

You stay responsible for what your app says. An assistant speaks under your name, in your app, in your colors. Test it with your real questions before publishing, including the awkward ones, and keep the instruction telling it to admit what it doesn't know. An assistant answering "I don't know, write to us" costs you nothing. An assistant inventing your opening hours costs you a customer.