Apps

An app is a small web application that belongs to your organization: a dashboard, a calculator, a form, an internal tool. You describe what you want in a chat, the App Builder writes it, and Tunori hosts it at an address of its own. You do not need to write or read any code.

Apps live under Apps in your organization. Building apps happens on the web; a published app opens in any browser, including on a phone.

Creating an app

Choose New app, give it a name and, if you like, an address. The address is the first part of the app's URL, for example sales-dashboard. Leave it empty to get one generated from the name.

• Addresses are unique across Tunori, use lowercase letters, numbers and single hyphens, and a few words are not allowed (for example anything that reads like a sign-in page or a well-known brand).
• You can change the address later, but the app then moves to a new URL: old links stop working, and anything the app stored in visitors' browsers stays behind at the old address.
• An address is never given to anyone else once an app has used it, whether the app was renamed or deleted. An app can take one of its own earlier addresses back.

Building with the App Builder

Open the app and choose Build (or Edit once it is published). The builder has a chat on the left and a live preview on the right.

• Describe the app, or the change you want, in plain language. Screenshots and sketches help; attach them to your message.
• The preview updates by itself within a second of every change the builder makes, so you watch the app take shape. It is only visible to editors of your organization.
• Opening the builder starts the app's building environment, which takes up to a minute. It is shut down again after 15 minutes without activity; your work is saved continuously, so nothing is lost and it simply starts again the next time.
• An app can have several builder chats. Start a new one from Chats when the topic changes; they do not appear in your organization's normal chat list.
• The Files tab shows the app's source code, read-only, with a button to download it as a zip.

Building apps needs a strong model, so the model picker in the builder only offers advanced and frontier models. A new builder chat starts on your organization's default app builder model (Settings → General, set by an organization admin), or on the platform's when none is chosen. See models and pricing.

What an app can and cannot do

Apps are web applications whose pages run in the visitor's browser and whose server-side code, its functions, runs on Tunori.

• An app has no database of its own. Data it shows is part of the app itself, is fetched by one of its functions each time, or is kept in the visitor's browser only (not shared with other visitors or devices). The builder will tell you when a request needs more than that.
• In the browser, an app can only load resources from, and talk to, its own address. Other websites, public services and your connected integrations are reached from its functions.
• An app knows who is looking at it: the visitor's name, email and role in your organization (or that they are anonymous, for a public app).
• While building, the App Builder can use your organization's connected integrations to look things up, and it asks for your approval before every such call. Anything it copies into the app becomes part of the app. Keep that in mind before making an app public.

For a bigger change the builder may hand parts of it to sub-agents. They work in the same app, one at a time, each on the files it was given; building and publishing a version stays with the builder itself.

Functions: server-side code and integrations

Ask for something the browser cannot do on its own ("show my newest emails in a table", "pull the exchange rate from a public API", "combine this week's calendar with my open tasks") and the builder writes a function: a small piece of server-side code the app calls while someone uses it. Functions run on Tunori, in an isolated sandbox, for at most 30 seconds per call. They can reach the internet and the tools of your integrations that you have granted to the app.

Granting tools. Before a function may use one of your integrations, the builder asks you to grant the app the specific tools it needs (for example Gmail's "search messages"). The approval card lists the integration and each tool. Approving means the app's own code decides what those tools are called with, for everyone who can use the app. The Integrations tab of the builder lists the granted tools and lets you revoke one; the builder asks again when a function needs a tool that is not granted.

Who can run a function:

• Every member who can open the app, viewers included. Granting a tool means sharing what it returns with everyone in your organization, like a dashboard.
• Anonymous visitors of a public app only if an admin turns on Functions: anyone next to the app's access setting. Then anyone on the internet can run each function, with any input, from any program, not only through the app's pages; a function may then use the granted tools on their behalf, as far as its code lets them. Runs are limited per visitor and per day. Turn it on only for apps whose functions you would publish on a web page.

Tool calls made by a function run under your organization's connected account (for Gmail, the mailbox you connected), and each one costs a tool call from your credit, like a tool call in a chat. Every function run and every tool call is logged (what was called, with which input, by whom; anonymous visitors by IP address) and kept for 90 days. Functions that change data (send an email, create a document) run for whoever can open the app, so consider carefully before granting such tools.

Functions cannot keep secrets: there is no way to give an app an API key of its own yet. Public APIs that need no key work; for anything else, ask us.

Versions and publishing

Nothing you do in the builder is visible to anyone else until you publish.

1. When the preview looks right, ask the builder to build a version (or to publish; it builds first). A version is a fixed snapshot of the app, numbered 1, 2, 3, …
2. Publish a version from the Versions tab, or ask the builder to publish, which always asks for your confirmation. The published version is what everyone gets at the app's address.
3. To go back, publish an older version from the same list.

A build that fails is listed too, with its output, so the builder (or you) can see what went wrong.

Every build, functions included, is checked for credentials such as API keys, access tokens and private keys. If one is found the version is not created, and the builder tells you where it is. An app cannot keep a secret; if a real key ended up in your app, revoke it.

Who can open an app

Only an admin of the organization can make an app public or members-only again, or allow anonymous visitors to run its functions; you find both settings next to the app's name. Making an app public also requires that your billing account has been topped up at least once; welcome credit alone is not enough. Before you make an app public, check what is in it: everything built into the app, including data copied in from your integrations, becomes visible to the whole internet.

Public apps show a small Built with Tunori badge with a Report link, which lets visitors tell us about abuse. Tunori may take an app offline if it is used for phishing, malware or other abuse; an app that was taken down can only be restored by Tunori.

Roles work as everywhere else in Tunori: viewers can open apps, editors and admins can create, build and publish them. See teams and roles.

Inside Tunori the app is shown embedded in the page. Some browsers block the sign-in an embedded page needs (older versions of Safari in particular); you then see a short notice with a link that opens the app in its own tab, where it always works.

What apps cost

Building an app is a chat like any other, so it uses credit for the model's tokens and for tool calls. Two things are specific to apps:

• Builder time — €0.50 per hour, charged by the minute while the app's building environment is running. It stops 15 minutes after you stop working.
• Hosting — €0.10 per published app per day, for members-only and public apps alike. Apps that have no published version cost nothing to keep.

If your credit cannot cover a day's hosting fee, your published apps go offline that day and show a "temporarily unavailable" page. Nothing is deleted: they come back by themselves within a few minutes of a top-up. To keep that from coming as a surprise, the organization's admins get an email when the credit covers only about seven more days of hosting, again at three days, and when the apps go offline, and the builder shows a warning while credit is low. These estimates only count hosting; chats and agents use the same credit, so it can run out sooner.