Return Users to Your App After a Profile Edit

Link a signed-in user into the hosted Unidy profile page with a return_to parameter, and Unidy sends them back to your application once they have saved their data.

The hosted profile page is the /profile page Unidy serves for your users. The User Manual calls the same page the Profile Cockpit — the two names describe one page, not two features.

The whole integration is one URL, plus one allow-list entry:

https://xxx.unidy.de/profile?return_to=https%3A%2F%2Fapp.example.com%2Faccount&return_to_name=Acme%20Portal

📋

Applies to web and native applications that link users into the hosted profile page (/profile) instead of embedding the SDK profile.

Prerequisites a Unidy tenant, dashboard access to allow-list your return target, and a signed-in user session in the browser you open.

Estimated time 10 minutes.

⚠️

This feature is in staged rollout and is switched off by default. Ask your Unidy contact to enable the enable_return_to_banner flag for your instance before you test it. While it is off, the parameters below are ignored entirely.

How it works

The classic use case is a Change my data button in your application: the user is already signed in, edits their data in Unidy, and expects to land back where they started.

Your app                           Unidy                              Your app
   |                                 |                                   |
   |  open /profile?return_to=...     |                                   |
   |-------------------------------->|                                   |
   |                                 | 1. validate target against the    |
   |                                 |    allow-list                     |
   |                                 | 2. store it for 1 hour, bound to  |
   |                                 |    the signed-in user             |
   |                                 | 3. show a "Back to ..." banner    |
   |                                 |                                   |
   |                                 |  user saves the profile           |
   |                                 |---------- redirect -------------->|
   |                                 |  or clicks the banner link        |
   |                                 |---------- redirect -------------->|

If the target is not allow-listed, Unidy ignores it silently: no banner, no redirect, and the profile page still works normally. A misconfigured link never breaks the page for the user.

Step 1: Allow-list your return target

Unidy only redirects to targets you have approved. A target is accepted if it matches either of these lists.

List	Where to configure it	Use it when
External Redirect Hosts	Auth → Security → Account & Access	The target applies tenant-wide. This is the same list used by invitation and password-reset redirects.
Allowed hosts on an SDK client	Integrations → SDK → SDK Clients, on the SDK client of the brand	You already run the Unidy SDK and do not want to maintain the same hosts twice.

Each entry is a full URI, not a bare hostname:

Entry	Matches
`https://example.com`	Any path on `example.com` over HTTPS.
`https://*.example.com`	`example.com` and any of its subdomains.
`https://example.com/portal`	`/portal` and anything below it, but no other path.
`myapp://profile-done`	A custom app scheme, for returning into a native app.

Matching rules:

The scheme must be identical. An http:// target never matches an https:// entry, and a custom scheme never matches an HTTP entry.

The host must match exactly, unless the entry starts with *..

The port must match. https://example.com:8443 needs its own entry.

The path acts as a prefix. An entry with no path, or with just /, allows every path on that host, so https://example.com and https://example.com/ are equivalent.

The schemes javascript:, data:, vbscript:, file:, blob: and about: are always rejected, whatever you configure.

Either list can hold as many entries as you need. A single link still carries exactly one return_to target.

For local development, add the full origin including the port, for example http://localhost:3000.

Changes to either list take effect immediately. You do not need a deploy or a restart.

Step 2: Link the user to the profile page

Open the profile page with the return target as a query parameter:

https://xxx.unidy.de/profile?return_to=https%3A%2F%2Fapp.example.com%2Faccount&return_to_name=Acme%20Portal

Parameter	Required	Description
`return_to`	Yes	The absolute, URL-encoded target to send the user back to. Maximum 2048 characters.
`return_to_name`	No	The name of your application, shown in the banner as Back to Acme Portal. Truncated to 60 characters. Without it, the banner shows the host name, or Back to the app for custom app schemes.

What return_to accepts:

An absolute URL with a scheme. Relative targets such as /account are rejected, so pass the full URL.

Query parameters and fragments are allowed and are preserved exactly as you sent them.

URL-encode the complete value. If you do not, your target's own query parameters are read as parameters of the profile page instead.

There is no SDK helper for this. You build the URL yourself, in whatever language your application uses.

🔒

The allow-list is an open-redirect guard: Unidy never sends a user to a target you have not approved. Keep that guarantee on your side too, and build return_to from values you control rather than from untrusted input in your own application.

☝️

The parameters are only read on /profile itself. Adding them to any other Unidy page has no effect.

The user must already be signed in to Unidy, otherwise they are asked to sign in first. For native apps, generate a session with a One Time Login Tokens for the path /profile and append the two parameters to that path.

Step 3: The user returns to your application

The user gets two ways back, and you do not have to choose between them.

Way back	What happens
Saving the profile	The first successful save redirects the user to your target instead of back to the profile page, and consumes the stored target. Later saves stay on the profile page.
The banner link	A Back to ... banner appears at the top of the page. Following it returns the user without saving, and leaves the stored target in place, so a save afterwards still redirects.

The banner stays visible on every Unidy page with the standard header, not just the profile page, so a user who wanders into newsletters or tickets can still get back. The user can dismiss it with the × button, which drops the stored target for good.

If a save fails validation, the profile page is redisplayed with the errors, the banner stays, and the stored target is untouched — the next successful save still returns the user to your application.

Lifetime and limits

Behaviour	Detail
Validity	1 hour after the user opens the link.
Storage	An encrypted, HTTP-only cookie in the user's browser. Nothing is stored server-side, and nothing is shared between browsers or devices.
User binding	The target belongs to the user who opened the link. If somebody else signs in on the same browser, it is ignored.
Consumed by	The first successful profile save, or the dismiss button.
Precedence	If the user arrives in the middle of an OAuth connect flow (with an `oauth_application_id` parameter), that flow decides where the user goes after saving.

Common errors

Symptom	Cause	Fix
No banner, and saving stays on the profile page	The target does not match any allow-list entry. Most often a subdomain without a `*.` entry, a different port, a path outside the allowed prefix, or `http://` against an `https://` entry.	Add or widen the entry in Auth → Security → Account & Access or on the SDK client.
Nothing happens even though the target is allow-listed	The rollout flag is still off for your instance.	Ask your Unidy contact to enable it.
The banner was there and is now gone	The target was consumed by a save, dismissed by the user, or is older than an hour.	Send the user through the link again.
The second save does not redirect	Expected: only the first save returns the user to your application.	Link the user again if they should return more than once.
The redirect stays inside Unidy	The parameters were added to a page other than `/profile`.	Put them on the `/profile` URL itself.
Profile updated appears later, on an unrelated Unidy page	Expected: the confirmation message is prepared before the user leaves the domain, so they see it the next time they open a Unidy page.	Show your own confirmation in your application after the return.
Only part of your target is used, or its parameters go missing	The `return_to` value was not URL-encoded, so its own query parameters were read as parameters of the profile page.	Encode the complete value.
Nothing happens, and the target is a path such as `/account`	Relative targets are rejected. Only absolute URLs with a scheme are accepted.	Pass the full absolute URL.
It works in production but not on your own machine	The development origin is missing from the allow-list, or its port does not match.	Add the full origin including the port, for example `http://localhost:3000`.

Next steps

One Time Login Tokens — sign a user in from your native app and deep-link them to /profile.

Profile Cockpit — what users can see and edit on the hosted profile page, and how to configure it.