To implement a settings flow with a server-side front-end and a back-end that submits the settings flow, you should always create (initialize) the settings flow when the user visits the settings page, not when the update is submitted. ### Why? - The flow must be initialized before rendering the settings form. The flow contains important information such as CSRF tokens, available methods, and the current state of the user's session. This information is required to render the form securely and correctly. - The flow is tied to the user's session and browser context. For browser-based flows, Ory Kratos sets cookies (including CSRF tokens) that are necessary for secure form submission. If you try to create the flow only at submission time (i.e., when the user submits the form), you will not have the required CSRF token and other flow data, and the request will likely fail due to missing or invalid security context. ### How to do it 1. When the user navigates to the settings page: - Your server-side front-end should call the settings flow initialization endpoint (

/self-service/settings/browser

) using the user's session cookie. - The response will be a redirect to your configured settings UI URL with a

?flow=<flow-id>

parameter, or, if you use AJAX, a JSON object with the flow data. - Use the flow data to render the settings form, including the CSRF token and any other required fields. 2. When the user submits the form: - The form should submit to the action URL provided in the flow data, including the

flow

ID and CSRF token. - Your back-end can handle the submission by forwarding the data to the Ory Kratos

/self-service/settings

endpoint, ensuring the session cookie and CSRF token are included. Do not create the flow only at submission time. The flow must exist before the form is rendered, as it provides the necessary context and security tokens for the update to succeed. #### Example - Initialize flow when user visits settings page:

bash   curl -s -i -X GET \     --cookie $cookieJar --cookie-jar $cookieJar \     -H "Accept: text/html" \     <https://playground.projects.oryapis.com/self-service/settings/browser>

This returns a redirect to your settings UI with the

flow

parameter, or JSON if using AJAX. Use this to render the form with the correct CSRF token and action URL. - Submit the form using the flow data: The form posts to the action URL from the flow, including the CSRF token and updated settings fields. For more details and code examples, see the official documentation on [settings flows for server-side browser clients](https://www.ory.sh/docs/kratos/self-service/flows/user-settings#user-and-profile-settings-for-server-side-browser-clients) and [custom UI integration basics](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration). > Summary: > Always initialize the settings flow when the user visits the settings page. Do not create the flow only at submission time. The flow provides the necessary context and security for the settings update to work correctly and securely [User and profile settings for server-side browser clients](https://www.ory.sh/docs/kratos/self-service/flows/user-settings#user-and-profile-settings-for-server-side-browser-clients) [Integration basics](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration).

No, you should not create an API settings flow for a server-side front-end. The knowledge sources are very clear: API flows are strictly intended for native applications (such as mobile apps, smart TVs, or command-line interfaces) and must not be used for browser-based applications, including server-side rendered web apps. Using API flows in browser-based apps exposes you to security risks, especially CSRF attacks. For server-side rendered front-ends, you must use the browser settings flow (

/self-service/settings/browser

). This ensures that all necessary security measures, such as CSRF protection and session management, are correctly applied. The API flow (

/self-service/settings/api

) is only for native clients and is not safe for browser contexts—even if your front-end is rendered on the server side, it is still a browser application from Ory's perspective. > Never use API flows to implement Browser applications! Using API flows in Single-Page-Apps as well as server-side apps opens up several potential attack vectors, including Login and other CSRF attacks. [User and profile settings updates for API clients and clients without browsers](https://www.ory.sh/docs/kratos/self-service/flows/user-settings#user-and-profile-settings-updates-for-api-clients-and-clients-without-browsers) [Integration basics](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration)

The purpose of starting the flow from the front-end (browser) is to ensure that all necessary security measures—especially CSRF protection and session management—are correctly established between the user's browser, your UI, and Ory. When you initialize the flow from the front-end, Ory can set and validate cookies (such as CSRF and session cookies) in the user's browser context, which are essential for secure operation of browser-based flows. You cannot start the flow in the back-end for browser-based applications because: - CSRF and session cookies must be set in the user's browser. These cookies are critical for security and are only properly set when the flow is initialized from the browser context. If you start the flow in the back-end, the cookies would not be set in the user's browser, breaking the security model and potentially causing the flow to fail. - Ory distinguishes between browser and API flows for security reasons. Browser flows are designed to work with browser security features, while API flows are for native clients that do not use cookies for CSRF/session management. Using the wrong flow type can expose your application to security vulnerabilities, such as CSRF attacks [Integration basics](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration) [User and profile settings for server-side browser clients](https://www.ory.sh/docs/kratos/self-service/flows/user-settings#user-and-profile-settings-for-server-side-browser-clients). In summary: The flow must be started from the front-end so that Ory can set the required cookies in the user's browser, ensuring secure and correct operation of the flow. Starting the flow in the back-end would bypass these security mechanisms and is not supported for browser-based applications.

This is a great question. The knowledge sources do not provide specific, concrete examples of what can go wrong if you do not use a flow for the settings page, but they do explain the underlying reasons and risks. Why does the settings page need a flow? Ory’s self-service flows (like settings, login, registration) are designed to handle complex security requirements, such as: - CSRF protection: Ory issues anti-CSRF cookies and tokens as part of the flow initialization. These are required to prevent cross-site request forgery attacks, which are a significant risk for actions that change user data. - Session management: The flow ensures that the user’s session is valid and meets the required assurance level (e.g., if 2FA is required). - Stateful operations: The flow tracks the state of the operation (e.g., whether the user needs to re-authenticate for privileged actions). If you skip the flow and try to update settings directly, you lose these protections. For example, without a valid CSRF token, a malicious site could trick a logged-in user into submitting a request to change their email or password. Why don’t other endpoints (like placing an order) need a flow? Ory’s self-service flows are specifically for sensitive identity operations—login, registration, settings, recovery, etc.—where the risk of account takeover or data leakage is high. Regular application endpoints (like placing an order) are not managed by Ory and are expected to implement their own security (such as CSRF protection) as appropriate for your application. What can go wrong if you don’t use a flow? - CSRF attacks: Without the flow, CSRF tokens are not set or validated, making it possible for attackers to perform actions on behalf of users. - Session hijacking or privilege escalation: The flow checks session validity and assurance level, which is not enforced if you bypass it. - Loss of audit and state tracking: Ory uses flows to track the state and context of sensitive operations. > Never use API flows to implement Browser applications! Using API flows in Single-Page-Apps as well as server-side apps opens up several potential attack vectors, including Login and other CSRF attacks. [User and profile settings updates for API clients and clients without browsers](https://www.ory.sh/docs/kratos/self-service/flows/user-settings#user-and-profile-settings-updates-for-api-clients-and-clients-without-browsers) In summary: The settings flow is required to ensure security for sensitive identity operations. Other endpoints in your application are outside Ory’s scope and must be secured by your own application logic. If you bypass the flow, you risk exposing your users to serious security vulnerabilities.

The knowledge sources do not explicitly state whether the settings flow profile method is a PATCH or PUT operation at the HTTP level. However, the API expects a payload containing the

traits

object with the updated identity traits. Regarding which traits to send: The API schemas and examples show that the

traits

object is required in the request body when using the profile method. The documentation and API references do not clarify whether partial updates are supported (i.e., sending only the fields you want to update) or if you must send all traits every time. However, typical usage and examples suggest that you should send the full set of traits as defined by your identity schema, not just the ones you want to update. This is because the traits object is validated against your schema, and missing required fields may result in validation errors. Example request body:

json {   "method": "profile",   "traits": {     "email": "<mailto:user@example.com|user@example.com>",     "name": "John Doe",     "phone_number": "+123456789"   } }

If your schema requires

email

,

name

, and

phone_number

, you should include all three in the

traits

object when updating the profile. Omitting required traits may cause validation errors. > The

traits

field is required in the request body for the profile method, and it is described as "The identity's traits" in the API reference. The documentation does not specify support for partial updates, so you should send all required traits as per your identity schema [Ory API Reference – updateSettingsFlow](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json). If you need confirmation on partial updates, you may want to test with your schema or consult the latest Ory documentation or community discussions.