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. Everything here is read-only except creating a blank app, adding a page, adding and removing app users, creating and changing user groups, toggling login, configuring sign-up and the email sender, previewing, and publishing. 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 an app

create_application 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 preview_app to look at it and publish_app when you want it live. By default it is created in your default workspace; pass a workspace to choose where it goes (use list_workspaces 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.

​

Adding a page

create_page 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 preview_app to look at it first, then publish_app when you want it out there. A Studio tab you already have open won’t show the new page until you reload it.

​

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.

​

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 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. get_user_connection says so plainly rather than letting an assistant invent a rule. 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 update_user_group.

​

Managing app users

These tools manage an app’s end users — the people who log in to the published app — not builders or collaborators. list_application_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. add_application_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. remove_application_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. set_application_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

set_application_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.

​

Sign-up settings

configure_application_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.

​

Email sender

configure_application_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 list_workspace_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?”, get_application includes an emailSender field with the sender’s name, email, confirmation state, and whether it is the default one.

​

Previewing and publishing

preview_app 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. publish_app 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.