Applications

These tools let an assistant understand how an app is built — its pages, its blocks, and who can see what — and then show you a change or make it live.

Most of these tools only read. The ones that change something create or rename an app, add a page, manage navigation menus, app users, user groups and data restrictions, change the app’s login, sign-in, sign-up, session, email sender, subdomain and custom-domain settings, preview it, and publish it. An assistant can add an empty page, but filling it with content is done through vibe coding blocks — and changes to an existing page’s content are made the same way.

Creating and renaming an app

application_create spins up a fresh, empty app with a default home page and returns its id, name, and workspace. The new app is not published — use application_preview to look at it and application_publish when you want it live. By default it is created in your default workspace; pass a workspace to choose where it goes (use workspace_list to find one). You can also pass a name for the app; omit it and Softr auto-generates one. From there, add content with vibe coding blocks.

application_set_name changes only the name you see in Studio. The subdomain, custom domain and app URL stay the same, and the new name applies straight away, without a publish. App names are unique within a workspace: if another app already has the name, Softr adds the first free suffix, such as “Bug Tracker (2)”, and the response says which name the app got.

Adding a page

application_page_create takes a name and a path — the name is the label you see in Studio’s page list, the path is the URL your visitors see (/pricing). Both are required, and both have to be unused in that app; the assistant will be told which one clashed if you pick something taken. A leading slash is added for you, so “pricing” and “/pricing” mean the same thing.

The page arrives empty. It inherits the app’s default visibility — logged-in users only if the app has login enabled, everyone otherwise — and lands at the top level of your page list, so move or nest it in Studio if you want it somewhere else. To put something on it, ask for a vibe coding block next.

A page you add is not live until you publish. Use application_preview to look at it first, then application_publish when you want it out there. A Studio tab you already have open won’t show the new page until you reload it.

Deleting a page

application_page_delete removes a page you no longer want, such as one the assistant created by mistake. The assistant cannot bring the page or its blocks back, so it confirms with you first unless you already asked for that page to be deleted. If you only want the page empty, ask for its blocks to be removed instead.

Pages nested under the deleted one in Studio’s page list are kept and move up one level into its place, unless you ask for them to be deleted too. Deleting them too is refused if one of them is a page that cannot be deleted (see below). Navigation menu items that link to the page are not removed with it.

The page disappears from Studio straight away, but your live app keeps serving it until you publish again.

Navigation menus

An app’s navigation is the menu its pages show: a top bar, a sidebar, or a bottom bar on mobile. An app can have several navigations, and each page shows one of them or none.

A menu item is a link to a page, a link to a URL, or a category that groups other items. To show different entries to different people on the same page, the assistant sets each item’s visibility by user group. Separate navigations are for different pages, not different users.

A new navigation is shown only on the pages you name. The exception is an app’s first navigation, which goes on every page. Deleting a navigation leaves the pages that showed it with no menu, and cannot be undone. These tools work on apps built with Softr’s current page builder; a legacy app is refused.

Reading an app

Before changing anything, the assistant needs to know what is there. This is how it finds the page you meant when you say “the dashboard”, and the block you meant when you say “the chart at the top”.

Permissions and user groups

Softr apps gate what end users see with user groups. These tools let the assistant read that setup, which is useful both for answering questions about it and for getting visibility right when it builds something new. It can also change the groups themselves — see Creating and changing user groups.

application_page_set_permissions changes a page’s Who can view setting, the same one as on the page’s Visibility settings in Studio. It covers the whole page, so a visitor it leaves out cannot open the page whatever its blocks allow. To narrow a page to particular user groups, it has to be set to logged-in users, and the groups you name replace the ones the page had before. Moving a page from logged-in users to any other setting also clears its groups. It works on regular pages only, not on utility pages such as log-in or sign-up. Like other app changes, it goes live on the next publish.

Connecting a users table

End-user login needs a table to authenticate against. Until an app has one, it has no end users to speak of and its groups can only be manual lists of email addresses.

The assistant browses to the table the same way it would for any data source — data source, then database, then table — and maps which of its fields hold what. Only the email field is required, since that is how an end user is identified; a name and avatar field are worth mapping too, because the app shows both.

Connecting asks for a user sync, which is what turns the table’s rows into app users. Apps are created with sync from source switched on, so this normally runs — but it can be paused from the users tab, and a paused app connects the table without importing anybody. The assistant tells you which happened rather than assuming.

Pointing an app at a different table

An app has one users table. To move it to another, the assistant replaces the connection rather than disconnecting and reconnecting — replacing validates the new table first, so a mistake leaves the app on the table it already had.

Disconnecting is gentler than it sounds: your existing app users remain and can still sign in, they just stop being updated from the table. New rows stop becoming users, rule-based groups can no longer be written, and the table itself is untouched. Reconnecting the same table restores the connection, and re-syncs the users unless sync from source is paused.

If all you want is to stop syncing without disconnecting, pause it from the users tab instead — that leaves the connection in place.

Creating and changing user groups

An assistant can create a custom group, rename it, change who is in it, or remove it.

A group is one of two kinds, and never both:

• Manual — an explicit list of app-user email addresses.
• Condition-based — a rule checked against each app user’s own record, so people join and leave the group as their data changes.

Switching between them is a switch rather than a merge: giving a group a member list drops any rule it had, and giving it a rule drops its member list.

A rule points at a field on the table that authenticates your end users, using that field’s ID rather than its name — which is what application_get_user_connection above is for. The same holds for a rule about a dropdown field: it matches the option’s ID, not the label you see. Both come back from that one call.

Rules are checked against a users table, so an app without end-user login can only have manual groups. application_get_user_connection says so plainly rather than letting an assistant invent a rule — and application_create_user_connection is how you fix it, after which rules work.

Three more limits worth knowing:

• The predefined groups — Logged in users, Visitors, Everyone — cannot be renamed, changed, or deleted. Only custom groups can.
• Names are unique within an app, ignoring case, so “Managers” and “managers” cannot both exist.
• Creating a group is capped by your plan’s allowance for custom user groups. Changing and deleting are not, so an app left over that limit by a downgrade can still be tidied up.

Deleting a user group

Page permissions and block or action-button visibility behave differently: they keep the deleted group’s ID, and the builder shows it as Deleted group. Nothing breaks, but anything that was visible only to that group is now visible to nobody until you fix it.

So after a delete, check what the group was gating. To change who is in a group rather than remove the group, use application_update_user_group.

Data restrictions

Data restrictions decide which records and fields each user group can see and change in a connected table. They apply on top of whatever a page, a block, or an app’s code does, so they are the first place to look when a record is missing from an app that looks correctly built.

A restriction ties one or more user groups to one table. It holds at most one rule per operation (view, edit, add, or delete), and each rule either blocks the operation or allows only it, for every record or for the records matching a condition, and for every field or only some of them. An operation without a rule is unrestricted.

A restriction listed with a group that has no name still points at a group that was deleted, and applies to nobody. It is usually a leftover worth removing.

Managing app users

These tools manage an app’s end users — the people who log in to the published app — not builders or collaborators.

application_list_users returns the app’s users page by page — first 10 by default, with limit (up to 100) and a 0-based page, plus the total and whether there is more. Pass query to search: a case-insensitive fragment matched against each user’s email and name, exactly like the search box on the app’s Users tab. Each user comes back with their id, email, name, status, whether they are active, when they were added, when they last signed in, and the custom user groups they belong to. Listing only needs read access to the app.

application_add_user takes both a name and an email and creates the user in the app. It fails if a user with that email already exists there. application_remove_user deletes the user with the given email, and fails if no user with that email exists in the app. These need write access to the app.

application_set_user_activation is the reversible alternative to removing: a deactivated user cannot sign in, but their account and data stay, and activating them again restores their previous status. Pass active=true to activate or active=false to deactivate; the call fails if no user with that email exists in the app.

Login settings

application_set_login turns the app’s end-user login on or off — pass enabled=true to turn it on, enabled=false to turn it off. Disabling login stops end users from signing in to the app; it is reversible, so calling it again with enabled=true restores login. It applies only to apps that support login — apps without login settings are rejected. Changes take effect on the next publish, like other app changes.

To see whether login is on without changing it, the assistant reads the app with application_get, whose login field holds the app’s login, sign-in and sign-up settings.

Turning login off does not change any page’s own Who can view setting. A page still set to logged-in users can then not be opened by anyone, so when you want the app public, also set those pages to all users with application_page_set_permissions.

Sign-in methods

application_configure_sign_in changes how end users sign in. Each setting is optional, and one you leave out keeps its current value:

• Email sign-in — on or off.
• Permanent login link — a link that signs a user in without a password and keeps working. Anyone who gets hold of a user’s link can sign in as them, so the assistant is told to warn you and ask before turning it on.
• Email login methods — password, a one-time code sent by email, or both, in which case a user can use either. Choosing a single method also turns off a setup where users need both. One-time codes need a paid plan.
• Strong passwords — require at least 12 characters with upper and lower case, a number and a symbol.
• One-time code lifetime — 1, 2, 5 (the default), 10 or 30 minutes.

The response is the app’s resulting sign-in settings, the same ones application_get returns. At least one sign-in method has to stay on, so a change that would leave none is refused.

Google sign-in, SSO and two-factor sign-in with an authenticator app cannot be changed through these tools: Google and SSO need credentials from Google or your identity provider, and the authenticator app needs your app’s sign-in screens to handle the second step. application_get reports whether each one is on, and the assistant gives you a link to the matching setting on the Authentication tab in Studio, where you set it up yourself. Don’t paste client secrets into the chat.

Session length

A login lasts 24 hours, 7 days, 30 days or 90 days (the default). Separately, users can be logged out after 5, 15 or 30 minutes, 1 hour or 3 hours without activity, or never (the default). Shorter values make your users sign in more often. Anything other than the defaults needs a plan with advanced security, and like login it applies only to apps that support login.

Sign-up settings

application_configure_sign_up controls whether — and who — end users can sign up. Set policy to one of:

• DISABLED — no one can sign up
• OPEN_TO_PUBLIC — anyone can sign up
• DOMAIN_RESTRICTED — only people whose email is in allowedDomains can sign up

allowedDomains is a list of email domains like ["example.com"]; it is required for DOMAIN_RESTRICTED and cleared for the other policies. Like login, it applies only to apps that support sign-up — apps without login settings are rejected — and changes take effect on the next publish.

To see the current policy without changing it, the assistant reads login.signUp from application_get.

Email sender

application_configure_email_sender controls the sender the app’s invites, magic links, and notifications go out from. What you pass selects what happens:

• name and email — registers the sender on the workspace (or renames it if that email is already registered) and assigns it to the app. This changes workspace-wide state, so it needs workspace-wide write access and a plan that includes custom senders.
• email only — assigns a sender that already exists on the workspace to the app. This only changes the app, so app-level write access is enough. Use workspace_list_email_senders to see what exists.
• neither — resets the app to the default Softr sender (its subdomain’s @softr.app address).

To answer “what sender is my app using?”, application_get includes an emailSender field with the sender’s name, email, confirmation state, and whether it is the default one.

workspace_verify_email_sender reports both checks for a sender, and returns the two DNS records to add at your DNS provider. Ask for the check once you have added them. DNS changes usually show up within minutes but can take up to 24 hours, so a record that is not verified yet is worth checking again later.

Subdomain and custom domain

application_set_subdomain changes the label in front of the app’s zone — pass my-app to get my-app.softr.app. The zone itself can’t be changed, the label must be a valid DNS label (a-z, 0-9, hyphens), and the subdomain must not be in use by another app.

application_set_domain takes a bare hostname like app.example.com; an apex domain like example.com is stored as www.example.com, so read the domain back from the response. Omit the domain to disconnect it and return to the subdomain. Custom domains require a plan that includes them.

Previewing and publishing

application_preview is how you look at a change before anyone else does. It builds the app from the current builder state, so it includes work that has not been published, and you can ask it to open on a specific page so you land where the change is. It publishes nothing — the live app and its visitors are untouched.

application_publish makes changes live. Two things to know before you ask for it:

• It publishes the whole app, not the page or block you were working on. Every unpublished change goes live at once, including ones made earlier or by someone else. If other people are working in the same app, check with them first.
• It cannot be undone from here. There is no unpublish tool yet, so an assistant can take an app live but cannot take it back down. To do that, unpublish the app yourself in Studio, under the app’s Settings → General.