docs: fix broken links (#8421)

# Which Problems Are Solved
^Since publishing the new V2 GA APi, we have a lot of broken links in
our docs

# How the Problems Are Solved

replace api links with v2 links

docs/docs/apis/introduction.mdx

@@ -21,7 +21,7 @@ Please refer to our guides how to [authenticate users](/docs/guides/integrate/lo
 
 For user authentication on devices with limited accessibility (eg, SmartTV, Smart Watch etc.) use the [device authorization grant](/docs/guides/integrate/login/oidc/device-authorization).
 
-Additionally, you can use the [session API](../apis/resources/session_service/) to authenticate users, for example by building a [custom login UI](/docs/guides/integrate/login-ui/).
+Additionally, you can use the [session API](../apis/resources/session_service_v2/) to authenticate users, for example by building a [custom login UI](/docs/guides/integrate/login-ui/).
 
 ### Authenticate service users and machines
 
@@ -45,7 +45,7 @@ The [OIDC Playground](/docs/apis/openidoauth/authrequest) is for testing OpenID
 
 ### Custom
 
-ZITADEL allows to authenticate users by creating a session with the [Session API](/docs/apis/resources/session_service) or get OIDC authentication request details with the [OIDC service API](/docs/apis/resources/oidc_service).
+ZITADEL allows to authenticate users by creating a session with the [Session API](/docs/apis/resources/session_service_v2) or get OIDC authentication request details with the [OIDC service API](/docs/apis/resources/oidc_service).
 User authorizations can be [retrieved as roles from our APIs](/docs/guides/integrate/retrieve-user-roles).
 
 Refer to our guide to learn how to [build your own login UI](/docs/guides/integrate/login-ui)
@@ -54,9 +54,9 @@ Refer to our guide to learn how to [build your own login UI](/docs/guides/integr
 
 ZITADEL provides APIs for each [core resource](/docs/apis/v2):
 
-- [User](/docs/apis/resources/user_service)
-- [Session](/docs/apis/resources/session_service)
-- [Settings](/docs/apis/resources/settings_service)
+- [User](/docs/apis/resources/user_service_v2)
+- [Session](/docs/apis/resources/session_service_v2)
+- [Settings](/docs/apis/resources/settings_service_v2)
 
 :::info
 We are migrating to a resource-based API approach.

docs/docs/guides/integrate/login-ui/_list-mfa-options.mdx

@@ -2,7 +2,7 @@ Your user has successfully authenticated, and now you ask them if they want to s
 When the user starts the configuration, first you want to show them the possible methods.
 You can either list it implicitly or call the settings service from ZITADEL to get what is configured on the login settings.
 
-More detailed information about the API: [Get Login Settings Documentation](/apis/resources/settings_service/settings-service-get-login-settings)
+More detailed information about the API: [Get Login Settings Documentation](/apis/resources/settings_service_v2/settings-service-get-login-settings)
 
 Request Example:
 

docs/docs/guides/integrate/login-ui/_logout.mdx

@@ -1,5 +1,5 @@
 When your user is done using your application and clicks on the logout button, you have to send a request to the terminate session endpoint.
-[Terminate Session Documentation](/docs/apis/resources/session_service/session-service-delete-session)
+[Terminate Session Documentation](/docs/apis/resources/session_service_v2/session-service-delete-session)
 
 Sessions can be terminated by either:
 - the authenticated user

docs/docs/guides/integrate/login-ui/_select-account.mdx

@@ -3,7 +3,7 @@ If you want to build your own select account/account picker, you have to cache t
 We recommend storing a list of the session Ids with the corresponding session token in a cookie.
 The list of session IDs can be sent in the “search sessions” request to get a detailed list of sessions for the account selection.
 
-[Search Sessions Documentation](/docs/apis/resources/session_service/session-service-list-sessions)
+[Search Sessions Documentation](/docs/apis/resources/session_service_v2/session-service-list-sessions)
 
 ### Request
 

docs/docs/guides/integrate/login-ui/_update_session_webauthn.mdx

@@ -2,7 +2,7 @@
 Now that you have successfully authenticated in the browser, you can update the session of the user.
 Fill the webAuthN checks with the credential assertion data you get from the browser.
 
-More detailed information about the API: [Update Session Documentation](/apis/resources/session_service/session-service-set-session)
+More detailed information about the API: [Update Session Documentation](/apis/resources/session_service_v2/session-service-set-session)
 
 Example Request:
 

docs/docs/guides/integrate/login-ui/external-login.mdx

@@ -20,7 +20,7 @@ Send the following two URLs in the request body:
 2. ErrorURL: Page that should be shown when an error happens during the authentication
 
 In the response, you will get an authentication URL of the provider you like.
-[Start Identity Provider Intent Documentation](/docs/apis/resources/user_service/user-service-start-identity-provider-intent)
+[Start Identity Provider Intent Documentation](/docs/apis/resources/user_service_v2/user-service-start-identity-provider-intent)
 
 ### Request
 
@@ -68,7 +68,7 @@ After the user has successfully authenticated, a redirect to the ZITADEL backend
 ZITADEL will take the information of the provider. After this, a redirect will be made to either the success page in case of a successful login or to the error page in case of a failure will be performed. In the parameters, you will provide the IDP intentID, a token, and optionally, if a user could be found, a user ID.
 
 To get the information of the provider, make a request to ZITADEL.
-[Retrieve Identity Provider Intent Documentation](/docs/apis/resources/user_service/user-service-retrieve-identity-provider-intent)
+[Retrieve Identity Provider Intent Documentation](/docs/apis/resources/user_service_v2/user-service-retrieve-identity-provider-intent)
 
 ### Request
 ```bash
@@ -155,7 +155,7 @@ Fill the IdP links in the create user request to add a user with an external log
 The idpId is the ID of the provider in ZITADEL, the idpExternalId is the ID of the user in the external identity provider; usually, this is sent in the “sub”.
 The display name is used to list the linkings on the users.
 
-[Create User API Documentation](/docs/apis/resources/user_service/user-service-add-human-user)
+[Create User API Documentation](/docs/apis/resources/user_service_v2/user-service-add-human-user)
 
 #### Request
 ```bash
@@ -193,7 +193,7 @@ curl --request POST \
 If you didn't get a user ID in the parameters to your success page, you know that there is no existing user in ZITADEL with that provider and you can register a new user (read previous section), or link it to an existing account.
 
 If you want to link/connect to an existing account you can perform the add identity provider link request.
-[Add IDP Link to existing user documentation](/docs/apis/resources/user_service/user-service-add-idp-link)
+[Add IDP Link to existing user documentation](/docs/apis/resources/user_service_v2/user-service-add-idp-link)
 
 #### Request
 ```bash

docs/docs/guides/integrate/login-ui/mfa.mdx

@@ -35,7 +35,7 @@ To show the user the QR to register TOTP with his Authenticator App like Google/
 Generate the QR Code with the URI from the response.
 For users that do not have a QR Code reader make sure to also show the secret, to enable manual configuration.
 
-More detailed information about the API: [Start TOTP Registration Documentation](/apis/resources/user_service/user-service-register-totp)
+More detailed information about the API: [Start TOTP Registration Documentation](/apis/resources/user_service_v2/user-service-register-totp)
 
 Request Example:
 
@@ -67,7 +67,7 @@ Response Example:
 When the user has added the account to the authenticator app, the code from the App has to be entered to finish the registration.
 This code has to be sent to the verify endpoint in ZITADEL.
 
-More detailed information about the API: [Verify TOTP Documentation](/apis/resources/user_service/user-service-verify-totp-registration)
+More detailed information about the API: [Verify TOTP Documentation](/apis/resources/user_service_v2/user-service-verify-totp-registration)
 
 Request Example:
 
@@ -93,7 +93,7 @@ curl --request POST \
 To be able to check the TOTP you need a session with a checked user. This can either happen before the TOTP check or at the same time.
 In this example we do two separate requests. So the first step is to create a new Sessions.
 
-More detailed information about the API: [Create new session Documentation](/apis/resources/session_service/session-service-create-session)
+More detailed information about the API: [Create new session Documentation](/apis/resources/session_service_v2/session-service-create-session)
 
 Example Request
 
@@ -131,7 +131,7 @@ Example Response
 Now you can show the code field to the user, where the code needs to be entered from the Authenticator App.
 With that code you have to update the existing session with a totp check.
 
-More detailed information about the API: [Update session Documentation](/apis/resources/session_service/session-service-set-session)
+More detailed information about the API: [Update session Documentation](/apis/resources/session_service_v2/session-service-set-session)
 
 Example Request
 ```bash
@@ -169,7 +169,7 @@ With an empty returnCode object in the request, ZITADEL will not send the code,
 
 If you don't want the user to verify the phone number, you can also create it directly as verified, by sending the isVerified attribute.
 
-More detailed information about the API: [Add phone](/apis/resources/user_service/user-service-set-phone)
+More detailed information about the API: [Add phone](/apis/resources/user_service_v2/user-service-set-phone)
 
 Example Request:
 
@@ -190,7 +190,7 @@ curl --request POST \
 The next step is to show a screen, so the user is able to enter the code for verifying the phone number.
 Send a verify phone request with the code in the body.
 
-More detailed information about the API: [Verify phone](/apis/resources/user_service/user-service-verify-phone)
+More detailed information about the API: [Verify phone](/apis/resources/user_service_v2/user-service-verify-phone)
 
 Example Request:
 ```bash
@@ -208,7 +208,7 @@ curl --request POST \
 
 Now that the user has a verified phone number you can enable SMS OTP on the user.
 
-More detailed information about the API: [Add OTP SMS for a user](/apis/resources/user_service/user-service-add-otpsms)
+More detailed information about the API: [Add OTP SMS for a user](/apis/resources/user_service_v2/user-service-add-otpsms)
 
 Example Request:
 ```bash
@@ -231,7 +231,7 @@ To be able to check the SMS Code you need a session with a checked user.
 When creating the session you can already start the sms challenge, this will only be executed if the user check was successful.
 You can tell the challenge, if the code should be returned (returnCode: true) or if ZITADEL should send it (returnCode: false).
 
-More detailed information about the API: [Create new session Documentation](/apis/resources/session_service/session-service-create-session)
+More detailed information about the API: [Create new session Documentation](/apis/resources/session_service_v2/session-service-create-session)
 
 Example Request
 
@@ -296,7 +296,7 @@ For the Email second factor the already verified email address will be taken.
 
 As the user already has a verified E-Mail address you can enable E-Mail OTP on the user.
 
-More detailed information about the API: [Add OTP Email for a user](/apis/resources/user_service/user-service-add-otp-email)
+More detailed information about the API: [Add OTP Email for a user](/apis/resources/user_service_v2/user-service-add-otp-email)
 
 Example Request:
 ```bash
@@ -319,7 +319,7 @@ To be able to check the Email Code you need a session with a checked user.
 When creating the session you can already start the sms challenge, this will only be executed if the user check was successful.
 You can tell the challenge, if the code should be returned (returnCode: true) or if ZITADEL should send it (returnCode: false).
 
-More detailed information about the API: [Create new session Documentation](/apis/resources/session_service/session-service-create-session)
+More detailed information about the API: [Create new session Documentation](/apis/resources/session_service_v2/session-service-create-session)
 
 Example Request
 
@@ -380,7 +380,7 @@ curl --request PATCH \
 The user has selected to setup Universal Second Factor (U2F).
 To be able to authenticate in the browser you have to start the u2f registration within ZITADEL.
 
-More detailed information about the API: [Start U2F Registration Documentation](/apis/resources/user_service/user-service-register-u-2-f)
+More detailed information about the API: [Start U2F Registration Documentation](/apis/resources/user_service_v2/user-service-register-u-2-f)
 
 Request Example:
 
@@ -450,7 +450,7 @@ Include the public key credential you got from the browser in your request.
 You can give the U2F a name, which makes it easier for the user to identify the registered authentication methods.
 Example: Google Pixel, iCloud Keychain, Yubikey, etc
 
-More detailed information about the API: [Verify U2F Documentation](/apis/resources/user_service/user-service-verify-u-2-f-registration)
+More detailed information about the API: [Verify U2F Documentation](/apis/resources/user_service_v2/user-service-verify-u-2-f-registration)
 
 Example Request:
 
@@ -491,7 +491,7 @@ In the creat session request you can check for the user and directly initiate th
 For U2F you can choose between "USER_VERIFICATION_REQUIREMENT_PREFERRED" and "USER_VERIFICATION_REQUIREMENT_DISCOURAGED" for the challenge.
 Best practice is using discouraged, as this doesn't require the user to enter a PIN. With `preferred` the user might be prompted for the PIN, but it is not necessary.
 
-More detailed information about the API: [Create new session Documentation](/apis/resources/session_service/session-service-create-session)
+More detailed information about the API: [Create new session Documentation](/apis/resources/session_service_v2/session-service-create-session)
 
 Example Request
 

docs/docs/guides/integrate/login-ui/oidc-standard.mdx

@@ -51,7 +51,7 @@ The endpoint will redirect you to the domain of your UI on the path /login and a
 ### Get Auth Request by ID
 
 With the ID from the redirect before you will now be able to get the information of the auth request.
-[Get Auth Request By ID Documentation](/docs/apis/resources/oidc_service/oidc-service-get-auth-request)
+[Get Auth Request By ID Documentation](/docs/apis/resources/oidc_service_v2/oidc-service-get-auth-request)
 
 ```bash
 curl --request GET \
@@ -80,7 +80,7 @@ Response Example:
 ### Perform Login
 
 After you have initialized the OIDC flow you can implement the login.
-Implement all the steps you like the user the go trough by [creating](/docs/apis/resources/session_service/session-service-create-session) and [updating](/docs/apis/resources/session_service/session-service-set-session) the user-session.
+Implement all the steps you like the user the go trough by [creating](/docs/apis/resources/session_service_v2/session-service-create-session) and [updating](/docs/apis/resources/session_service/session-service-set-session) the user-session.
 
 Read the following resources for more information about the different checks:
 - [Username and Password](./username-password)
@@ -95,7 +95,7 @@ On the create and update user session request you will always get a session toke
 
 The latest session token has to be sent to the following request:
 
-Read more about the [Finalize Auth Request Documentation](/docs/apis/resources/oidc_service/oidc-service-create-callback)
+Read more about the [Finalize Auth Request Documentation](/docs/apis/resources/oidc_service_v2/oidc-service-create-callback)
 
 Make sure that the authorization header is from the same account that you originally sent in the client id header ```x-zitadel-login-client: <userid>``` on the authorize endpoint.
 ```bash
@@ -145,4 +145,4 @@ In case the ZITADEL backend is not able to determine which session to terminate
 
 ```/logout?post_logout_redirect=```
 
-Prompt the user to select a session, terminate it using the [corresponding endpoint](/docs/apis/resources/session_service/session-service-delete-session) and send the user to the `post_logout_redirect` URL.
+Prompt the user to select a session, terminate it using the [corresponding endpoint](/docs/apis/resources/session_service_v2/session-service-delete-session) and send the user to the `post_logout_redirect` URL.

docs/docs/guides/integrate/login-ui/passkey.mdx

@@ -27,7 +27,7 @@ When you want to send a link to your user, that enables them to register a new p
 
 If you asked ZITADEL to send the link to the user please make sure to populate the link with the needed values that point towards your registration UI.
 
-More detailed information about the API: [Send Registration Link Documentation](/apis/resources/user_service/user-service-create-passkey-registration-link)
+More detailed information about the API: [Send Registration Link Documentation](/apis/resources/user_service_v2/user-service-create-passkey-registration-link)
 
 Request Example:
 Send either the sendLink or the returnCode (empty message) in the request body, depending on the use case you have.
@@ -74,7 +74,7 @@ By specifying the authenticator type you can choose if the passkey should be cro
 
 The API response will provide you the public key credential options, this will be used by the browser to obtain a signed challenge.
 
-More detailed information about the API: [Start Passkey Registration Documentation](/apis/resources/user_service/user-service-register-passkey)
+More detailed information about the API: [Start Passkey Registration Documentation](/apis/resources/user_service_v2/user-service-register-passkey)
 
 Request Example:
 The code only has to be filled if the user did get a registration code.
@@ -179,7 +179,7 @@ Include the public key credential you got from the browser in your request.
 You can give the Passkey a name, which makes it easier for the user to identify the registered authentication methods.
 Example: Google Pixel, iCloud Keychain, Yubikey, etc
 
-More detailed information about the API: [Verify Passkey Registration Documentation](/apis/resources/user_service/user-service-verify-passkey-registration)
+More detailed information about the API: [Verify Passkey Registration Documentation](/apis/resources/user_service_v2/user-service-verify-passkey-registration)
 
 Example Request:
 
@@ -218,7 +218,7 @@ First step is to ask the user for his username and create a new session with the
 When creating the new session make sure to include the challenge for passkey, resp. webAuthN with a required user verification and the domain of your login UI.
 The response will include the public key credential request options for the passkey in the challenges.
 
-More detailed information about the API: [Create Session Documentation](/apis/resources/session_service/session-service-create-session)
+More detailed information about the API: [Create Session Documentation](/apis/resources/session_service_v2/session-service-create-session)
 
 Example Request:
 ```bash

docs/docs/guides/integrate/login-ui/password-reset.mdx

@@ -16,7 +16,7 @@ The goal is to send the user a verification code, which can be entered to verify
 
 There are two possible ways: You can either let ZITADEL send the notification with the verification code, or you can ask ZITADEL for returning the code and send the email by yourself.
 
-[Request Password Reset Documentation](/apis/resources/user_service/user-service-password-reset)
+[Request Password Reset Documentation](/apis/resources/user_service_v2/user-service-password-reset)
 
 ### ZITADEL sends the verification message
 
@@ -84,7 +84,7 @@ From a user experience perspective it is nice to prefill the verification code,
 As soon as the user has typed the new password, you can send the change password request.
 The change password request allows you to set a new password for the user.
 
-[Change Password Documentation](/apis/resources/user_service/user-service-set-password)
+[Change Password Documentation](/apis/resources/user_service_v2/user-service-set-password)
 
 :::note
 This request can be used in the password reset flow as well as to let your user change the password manually.

docs/docs/guides/integrate/login-ui/session-validation.mdx

@@ -46,8 +46,8 @@ If a user successfully authenticated using username and password, a session coul
 Your application would then need to check whether these `factors` are enough, esp. if the `verifiedAt` of both are within
 an acceptable time range.
 
-To get the current state of the session, you can call the [GetSession endpoint](/apis/resources/session_service/session-service-get-session),
-resp. you can get several by [searching sessions](/apis/resources/session_service/session-service-list-sessions).
+To get the current state of the session, you can call the [GetSession endpoint](/apis/resources/session_service_v2/session-service-get-session),
+resp. you can get several by [searching sessions](/apis/resources/session_service_v2/session-service-list-sessions).
 
 ## Expiration
 

docs/docs/guides/integrate/login-ui/typescript-repo.mdx

@@ -43,14 +43,14 @@ _Note that the illustration is just a representation of the architecture and may
 The flow starts by the `/authorize` endpoint which is intercepted by the login and forwarded to ZITADEL.
 ZITADEL interprets the request and specifically redirects back to the login app.
 It does so by redirecting to `/login`.
-The login is then able to load an [AuthRequest](/docs/apis/resources/oidc_service/oidc-service-get-auth-request#get-oidc-auth-request-details).
+The login is then able to load an [AuthRequest](/docs/apis/resources/oidc_service_v2/oidc-service-get-auth-request#get-oidc-auth-request-details).
 
 The Auth Request defines how users proceed to authenticate. If no special prompts or scopes are set, the login brings up the `/loginname` page.
 The /loginname page allows to enter loginname or email of a user. User discovery is implemented at /api/loginname and if the user is found, they will be redirected to the available authentication method page.
 Right after the user is found, a session is created and set as cookie.
 This cookie is then hydrated with more information once the users continues.
 The OIDC Auth request is always passed in the url to have a context to the ongoing authentication flow.
-If enough user information is retrieved and the user is authenticated according to the policies, the flow is finalized by [requesting a the callback url](/docs/apis/resources/oidc_service/oidc-service-create-callback) for the auth request and the user is redirected back to the application.
+If enough user information is retrieved and the user is authenticated according to the policies, the flow is finalized by [requesting a the callback url](/docs/apis/resources/oidc_service_v2/oidc-service-create-callback) for the auth request and the user is redirected back to the application.
 The application can then request a token calling the /token endpoint of the login which is proxied to the ZITADEL API.
 
 ### Implemented features

docs/docs/guides/integrate/login-ui/username-password.mdx

@@ -10,7 +10,7 @@ sidebar_label: Username and Password
 ## Register
 
 First, we create a new user with a username and password. In the example below we add a user with profile data, a verified email address, and a password.
-[Create User Documentation](/apis/resources/user_service/user-service-add-human-user)
+[Create User Documentation](/apis/resources/user_service_v2/user-service-add-human-user)
 
 ### Custom Fields
 
@@ -88,8 +88,8 @@ Return Code:
 
 To check what is allowed on your instance, call the settings service for more information.
 The following requests can be useful for registration:
-- [Get Login Settings](/apis/resources/settings_service/settings-service-get-login-settings) To find out which authentication possibilities are enabled (password, identity provider, etc.)
-- [Get Password Complexity Settings](/apis/resources/settings_service/settings-service-get-password-complexity-settings) to find out how the password should look like (length, characters, etc.)
+- [Get Login Settings](/apis/resources/settings_service_v2/settings-service-get-login-settings) To find out which authentication possibilities are enabled (password, identity provider, etc.)
+- [Get Password Complexity Settings](/apis/resources/settings_service_v2/settings-service-get-password-complexity-settings) to find out how the password should look like (length, characters, etc.)
 
 ## Create Session with User Check
 
@@ -103,9 +103,9 @@ The create and update session endpoints will always return a session ID and an o
 If you do not rely on the OIDC standard you can directly use the token.
 Send it to the Get Session Endpoint to find out how the user has authenticated.
 
-- [Create new session Documentation](/apis/resources/session_service/session-service-create-session)
-- [Update an existing session Documentation](/apis/resources/session_service/session-service-set-session)
-- [Get Session Documentation](/apis/resources/session_service/session-service-get-session)
+- [Create new session Documentation](/apis/resources/session_service_v2/session-service-create-session)
+- [Update an existing session Documentation](/apis/resources/session_service_v2/session-service-set-session)
+- [Get Session Documentation](/apis/resources/session_service_v2/session-service-get-session)
 
 ### Request
 

docs/docs/guides/integrate/login/login-users.mdx

@@ -55,7 +55,7 @@ There are more [differences between SAML and OIDC](https://zitadel.com/blog/saml
 
 ### ZITADEL's Session API
 
-ZITADEL's [Session API](/docs/apis/resources/session_service) provides developers with a straightforward method to manage user sessions within their applications.
+ZITADEL's [Session API](/docs/apis/resources/session_service_v2) provides developers with a straightforward method to manage user sessions within their applications.
 The Session API is not an industry-standard and can be used instead of OpenID Connect or SAML to authenticate users by [building your own custom login user interface](/docs/guides/integrate/login-ui).
 
 #### Tokens in the Session API

docs/docs/guides/integrate/onboarding/end-users.mdx

@@ -119,7 +119,7 @@ You can find all the guides here: [Build your own login UI](/docs/guides/integra
 
 #### Custom fields
 
-The [create user request](/docs/apis/resources/user_service/user-service-add-human-user) also allows you to add [metadata](/docs/guides/manage/customize/user-metadata) (key, value) to the user.
+The [create user request](/docs/apis/resources/user_service_v2/user-service-add-human-user) also allows you to add [metadata](/docs/guides/manage/customize/user-metadata) (key, value) to the user.
 This gives you the possibility to collect additional data from your users during the registration process and store it directly to the user in ZITADEL.
 Those metadata can also directly be included in the [token](/docs/guides/manage/customize/user-metadata#use-tokens-to-get-user-metadata) of the user.
 We recommend storing business relevant data in the database of your application, and only authentication and authorization relevant data in ZITADEL to follow the separation of concern pattern.