Sign in / Sign up destination URL in query string?

Hi everyone!

I am new to softr but really love using it.

Is is possible to pass a “destination url” query string into a signin / signup form? Something like:

  1. user goes to “”
  2. user successfully signs in and is then routed to “

Have asked myself the same question, and would love for this to work! A large % of traffic lands on a list-detail page from Google, whereby the next step requires either signing-up or logging in. At the moment, you are redirected back to a generic list page rather than the page you were on previously.

yes, this is more-or-less our scenario as well. This is expected behavior for a user when signing in / up. We should be able to dynamically determine the destination URL.

I would propose that after sign in, if there is a “successUrl” in the query string, that should override the “On Sign In” default page setting Studio.

In many ways, this makes Softr unusable for us because we want to use it as our “app” alongside our SquareSpace static website. From SquareSpace, I need to be able to direct a user to a specific url in Softr after sign in…

This feature has been requested many times, and yes - it’s really a problem. I worked up a hack that allows a user to sign in “in place” on the destination page without having to go to a sign-in block and then come back.

thank you @dcoletta I will check this out. I’ve wasted several hours trying to manipulate the ‘successUrl’ in the sign in form DOM but softr’s code executes in the body before the dom is fully loaded, so I can’t change the data-successUrl attribute…

The only other approach I can think of to work around this limitation would be to embed sign-in and sign-up blocks on every page that you might be sending users to, so that the user lands on the correct page, and then after they successfully sign in or up, the page simply has to reload.

Of course this is really only practical if there is a small number of pages. It wouldn’t scale.

Oh wait there’s one other avenue to explore. You might want to check out the custom 401 page feature. When a user who is not logged in navigates to a page that is available only to logged-in users, they end up on a page with the URL they navigated to, but with custom “not signed in” content. It seems to me (I haven’t tried this) that you could put a sign-in or sign-up block on that page, and after the user completed that, a reload would end up displaying the page they wanted.

i did try putting a signin block on the /401, it didn’t work but I can’t remember why.

Currently I am trying to put an embed block just below my signin form with the following:

This does successfully change the data attribute of the correct dom object, but apparently the softr code has already run at this point and pulled the successurl from the dom. Though I can’t verify this using breakpoints to watch the code execution…

If you really had to, you could intercept the 201 response on successful sign-in, and before the Softr code gets a chance to run, you could either trigger a reload or change the location.

this issue is very frustrating to me b/c it is such basic expected behavior when signing into an app. Softr has so many cool advanced features, but this single limitation will likely mean we can’t use softr. Having a “deep linking” capability like this is critical.

I’ve been able to manipulate the DOM with this embedded code block just below my sign in form.

Per my breakpoints, it seems to run before the softr code grabs the successurl attribute, but still no luck…

yeah, looking at their code, this is impossible because the server returns the destination URL in the success callback and that over-rides the value in the DOM. So this is dead as far as I can tell unless they implement the feature.

1 Like

Did you try this?

@drew0 I have a hack that might do what you want.

The idea builds on putting a sign-in block on the custom 401 page.

Here’s what I did:

  • I created a page called /embedded-signin that has a sign-in block on it and whose destination page after a successful sign-in is another page I created called /just-reload
  • I created a page called /just-reload which is empty except for code in the Code Inside Footer that looks like this:
  • I embedded the /embedded-signin page as an iframe on the custom 401 page. (It might work to just embed that sign-in block instead of the whole page, but I didn’t try that.)
  • I also added to the custom 401 page a script that runs in the Code inside header and looks like this:
window.addEventListener('message', function (e) {
    if ( === 'reload') {

The net effect of all this hackery is that when the user navigates to a page in your app that requires them to be logged in but they’re not, they land on the custom 401 page, they see a sign-in block, they sign in, and then the page reloads with the content shown only to logged in users. During all this time the page URL is the page they were trying to get to, so from their point of view, it’s as friction-free as possible.


  • I’m not totally sure how robust this is
  • More work would be needed to support a sign-up flow as well

Does this seem like it might be a useful path to pursue?

Thank you everyone who offered advice and code samples! I do have this working now and maybe others can benefit from this.

First an explanation, when you sign in, softr first looks to see if you have specified an “page after sign in/up” for the User Group “Logged in Users”. If so, it uses that page as the destination post signin.

If you don’t have that value specified, softr use the “On Sign In - Page after sign in” value specified in the sign in block.

Note: this solution only works if you do not have the page specified for the User Group “Logged in Users” and unfortunately once you set a value it is not possible (per softr support) to clear it.

What I needed is to be able to specify the post-signin destination page in the URL. This is so I can route the user directly to a certain page behind the authentication wall. Like so:

The solution I came up with is to change the “On Sign In - Page after sign in” value dynamically after the sign-in page loads. This is possible because this url is stored as an attribute in the DOM.

So, on my sign-in page, I added a code block directly below my signin block with the following:


    /* get query params */
    const params = new Proxy(new URLSearchParams(, {
       get: (searchParams, prop) => searchParams.get(prop),
    /* post-sign-in redirect url */
    const queryStringSuccessUrl = params.url;
    if (queryStringSuccessUrl) {
        document.getElementsByClassName('form sw-js-form')[0].setAttribute('data-successurl', queryStringSuccessUrl);

This is working great for the base case, now I need to figure out how to pass the the query params back and forth b/t the signin and signup pages.

1 Like