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

​

Managing app users

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