Ory Kratos is designed to redirect users to the configured Error UI page (

selfservice.flows.error.ui_url

) when a user-facing error occurs during self-service flows. This is a core part of its error handling mechanism and is intended to allow you to present custom error pages to users in your own UI. If you do not set this configuration, Kratos will show a fallback message instructing you to set it, but it will not suppress the redirect behavior itself [User-facing errors](https://www.ory.sh/docs/kratos/self-service/flows/user-facing-errors) [This should be the Error UI](https://www.ory.sh/docs/kratos/fallback/error). There is no documented configuration option to prevent Kratos from redirecting to the error UI page entirely. The redirect is fundamental to how Kratos separates backend logic from frontend presentation. If you want to handle errors differently (for example, by consuming them directly in an API client), you should use the API flows, which return errors in the HTTP response instead of redirecting [User-facing errors](https://www.ory.sh/docs/kratos/self-service/flows/user-facing-errors). Summary: You cannot prevent Kratos from redirecting to the error UI page for browser-based flows via configuration. For API clients, errors are returned in the response and no redirect occurs. If you need more granular control, you would need to handle errors at the API level rather than through browser flows.

If you are using the API flow in Ory Kratos but are still experiencing redirects to the UI error page, this is unexpected according to the documented behavior. For API clients (such as mobile apps or AJAX requests), Kratos is supposed to return errors as JSON in the HTTP response, not perform a redirect to the error UI page. Redirects to the error UI are intended for browser-based flows only [User-facing errors](https://www.ory.sh/docs/kratos/self-service/flows/user-facing-errors). However, there are some edge cases and known issues where this behavior might not be consistent: - OIDC and Social Login Flows: There are reports that, in some cases (such as OIDC callbacks), even API flows may result in a redirect or a browser-based error handling, especially if the flow is initiated in a browser context or if the identity is inactive. This has been discussed as a bug/limitation in Ory Network, where the expectation is a JSON error but a redirect or browser error page is returned instead [OIDC callback returns 401 to browser when identity state is inactive](https://github.com/ory/network/issues/397). - Return_to Parameter and Error Handling: There is also a known issue where the

return_to

parameter is not respected for errors in API flows, and the user is redirected to the browser self-service UI instead. The workaround is to retrieve the flow and error details via the API and handle them in your client [

return_to

parameter of registration/login api flows don't work for errors](https://github.com/ory/network/issues/344). What you can do: - Double-check that you are initializing and submitting the flow using the

/self-service/*/api

endpoints and that your requests include the

Accept: application/json

header. - If you are using OIDC or social login, be aware that some error cases may still trigger a redirect due to current limitations. - For full control, always retrieve the flow or error details via the API endpoints and handle them in your client application. If you are following the API flow pattern and still see redirects, it may be due to one of these known issues or a misconfiguration. There is no documented configuration to force Kratos to never redirect in API flows, but the expected behavior is to return JSON errors for API clients. If this is not happening, it may be a bug or an edge case as described above.

To properly catch browser-based UI error redirects from Ory Kratos and render the error response in your own UI, follow this approach: 1. Configure the Error UI URL: In your Kratos configuration, set

selfservice.flows.error.ui_url

to point to your custom error page. When an error occurs, Kratos will redirect the browser to this URL with an

id

query parameter (e.g.,

/errors?id=abcde

) [User-facing errors](https://www.ory.sh/docs/kratos/self-service/flows/user-facing-errors). 2. Extract the Error ID: On your error page, extract the

id

parameter from the URL. 3. Fetch Error Details from Kratos: Use the error ID to fetch the error details from Kratos’ public API endpoint

/self-service/errors?id=<id>

. The response will contain structured error information. Example (using JavaScript in your error page):

js    const params = new URLSearchParams(window.location.search);    const errorId = params.get('id');    fetch(`https://<kratos-public-endpoint>/self-service/errors?id=${errorId}`)      .then(res => res.json())      .then(data => {        // Render error details in your UI        console.log(data.error.message);      });

4. Render the Error in Your UI: Use the error details (such as

code

,

message

,

reason

,

debug

) to display a user-friendly error message. Example error response:

json {   "id": "9f900efa-a5ea-4dfd-8311-a8c7448ffeec",   "error": {     "code": 500,     "status": "Internal Server Error",     "reason": "This is a stub error.",     "message": "An internal server error occurred, please contact the system administrator"   } }

You can use these fields to render a custom error page for your users [User-facing errors](https://www.ory.sh/docs/kratos/self-service/flows/user-facing-errors). Summary: - Set the error UI URL in Kratos. - On your error page, extract the error ID from the URL. - Fetch error details from Kratos using the error ID. - Render the error information in your UI. This approach gives you full control over how errors are presented to your users.