Multi-app deprecation: Will user id remain consistent across multiple Native App Keys?

beiyuanjing5890 · 4월 24, 2026, 10:17오후

안녕하세요,

TikTok에서 KakaoTalk 제3자 로그인 연동을 담당하고 있는 개발자입니다.

현재 TikTok 메인 앱과 TikTok Coin 등 여러 애플리케이션에서 Kakao 로그인 기능을 사용하고 있습니다.
여러 앱에서 동일한 Kakao 사용자를 식별하기 위해, 하나의 App Key에 여러 애플리케이션 패키지를 설정하는 multi-app 기능을 사용해 왔습니다.

최근 multi-app 기능이 7월 14일에 종료될 예정이라는 안내를 받았으며, 이에 따라 대체 방안을 검토하고 있습니다.

문서에서 확인한 바에 따르면, “creating more Native app keys” 방식으로 대체할 수 있는 것으로 이해하고 있습니다.
즉, TikTok과 TikTok Coin 등 각 애플리케이션이 서로 다른 Native App Key를 사용하는 구조입니다.

이와 관련하여 다음 사항을 확인하고 싶습니다:

서로 다른 Native App Key를 사용하는 경우, 동일한 Kakao 사용자에 대해 v2/user/me API에서 반환되는 id 값이 동일하게 유지되는지 궁금합니다.

현재 저희 서비스는 해당 id를 기반으로 사용자 식별 및 로그인 처리를 하고 있습니다.
만약 Native App Key를 분리한 이후 id 값이 변경된다면, Kakao 사용자가 정상적으로 로그인하지 못하는 문제가 발생할 수 있습니다.

이 동작에 대한 확인과 함께, 여러 앱 간 사용자 ID 일관성을 유지할 수 있는 권장 마이그레이션 방법이 있다면 안내 부탁드립니다.

감사합니다.

Hi,

I am a developer from TikTok, responsible for integrating KakaoTalk as a third-party login provider.

We currently use Kakao Login across multiple TikTok applications, such as the main TikTok app and TikTok Coin. In order to recognize the same Kakao user across these different applications, we have been using Kakao’s multi-app feature by configuring multiple application package names under a single App Key.

Recently, we received a notice that the multi-app feature will be deprecated on July 14. Therefore, we are evaluating alternative solutions.

From the documentation, we understand that one possible replacement is “creating more Native app keys”, meaning that each application (e.g., TikTok and TikTok Coin) would use its own separate Native App Key.

In this case, we would like to confirm the following:

If different applications use different Native App Keys, will the id returned by the v2/user/me API remain the same for the same Kakao user?

Currently, our authentication system relies on this id to identify users and complete login. If the id changes when switching to multiple Native App Keys, Kakao users may not be able to log in to our services.

We would appreciate your clarification on this behavior, as well as any recommended migration approach to ensure user ID consistency across applications.

Thank you in advance, and we look forward to your response.

woody.ho · 4월 27, 2026, 2:25오전

안녕하세요.

앱 키와 회원번호(ServiceUserID or /v2/user/me - id)

말씀처럼 여러 앱 키를 생성하여 멀티 앱 기능을 대체할 수 있습니다.
/v2/user/me의 id 값은 디벨로퍼스 앱에 종속적인 값 입니다. 따라서 같은 앱 하위에서는 여러 앱 키를 생성하고 사용 하더라도 이 값이 변경되지 않습니다.

AppKey, ServiceUserID (/v2/user/me - id)

It is possible to create multiple app keys to substitute for multi-app functionality.

The id value returned from /v2/user/me is tied to the Developers app. Therefore, within the same app, this value will remain unchanged even if multiple app keys are created and used.

beiyuanjing5890 · 4월 29, 2026, 10:49오후

Thank you for your previous response.

We would like to further inquire about ensuring service availability during the migration from multi-app to multiple Native App Keys.

1. Background

Currently, our setup is:

Multiple applications are configured under a single App Key (app_key_1) using the multi-app feature, including:
- pkg_name_1
- pkg_name_2
- bundle_id_1
- bundle_id_2

2. Planned Migration Approach

We plan to create new Native App Keys as follows:

app_key_new_1 for pkg_name_1 and bundle_id_1
app_key_new_2 for pkg_name_2 and bundle_id_2

We intend to gradually migrate traffic (e.g., via a phased rollout) from app_key_1 to the new App Keys.

During this process, we expect the existing multi-app configuration under app_key_1 to remain functional to ensure service continuity.

3. Questions

Question 1: Overlapping configuration during migration

During the migration, pkg_name_1 and bundle_id_1 will be associated with both:

the original app_key_1 (multi-app configuration), and
the new app_key_new_1

In this case:

Will this overlapping configuration cause any conflicts or unexpected behavior on Kakao APIs?
For example, could the id returned by v2/user/me change?
Are there any other API behaviors that may be affected?

Question 2: Recommended migration procedure (SOP)

Does Kakao provide any recommended migration procedure or best practices for transitioning from multi-app to multiple App Keys?

For example:

Suggested rollout strategy
Key steps or precautions to follow

Question 3: Migration tooling or automation support

Does Kakao provide any tooling or capability to assist with this migration, such as:

Automatically generating multiple App Keys based on existing multi-app configurations
Any other migration assistance tools

If not, should this process be handled entirely manually?

Question 4: Behavior after multi-app deprecation

After the multi-app feature is deprecated:

What will happen to applications that were previously configured under multi-app?
How will Kakao Login APIs behave (e.g., authorization/login)?
Will the original primary package name / bundle ID remain valid?
Will the multi-app configuration automatically become invalid?

Additionally:

Should we proactively remove multi-app configurations before the deprecation date to avoid any unexpected issues?

Question 5: App Key limit

The documentation states:

"You can create up to 5 app keys per platform environment in an app"

However, we currently have more than 5 bundle IDs (e.g., 6) configured via multi-app.

In this case:

If we migrate to multiple App Keys, we would need more than the allowed number of App Keys. How should we handle this situation?

Thank you again for your support. We look forward to your guidance.

tim.l · 4월 30, 2026, 3:39오전

Hello, @beiyuanjing5890

Will this overlapping configuration cause any conflicts or unexpected behavior on Kakao APIs?

For example, could the id returned by v2/user/me change?

Are there any other API behaviors that may be affected?

If the app key is correctly configured for both initialization and the redirect scheme, it will work properly by identifying the specific Developers app.

The package name is used as part of the combined scheme to return to the app after login.

The member number (ID) is issued on a per-Developers-app basis, so it does not affect the API itself.

However, if you are using a KakaoTalk sharing template, you should check the native app scheme setting in the common configuration for the landing destination.

Does Kakao provide any recommended migration procedure or best practices for transitioning from multi-app to multiple App Keys?

Since it only requires adding the native app key and updating the settings, we do not provide a separate guide for it.

Please test with the newly added app key first, then apply it to the production app. After that, you can remove the existing multi-app configuration at an appropriate time.

Does Kakao provide any tooling or capability to assist with this migration, such as:

Automatically generating multiple App Keys based on existing multi-app configurations

Any other migration assistance tools
If not, should this process be handled entirely manually?

Since changes are also required on the app you operate, automatic migration is not provided.

After the multi-app feature is deprecated:

What will happen to applications that were previously configured under multi-app?

How will Kakao Login APIs behave (e.g., authorization/login)?

Will the original primary package name / bundle ID remain valid?

Will the multi-app configuration automatically become invalid?
Additionally:
Should we proactively remove multi-app configurations before the deprecation date to avoid any unexpected issues?

After the new native app key is applied to the production app, the multi-app feature will remain available for a grace period to support users on older app versions.
Please let us know how long of a grace period you need.

You can keep both the multi-app configuration and the newly added native app key configuration in place for a certain period, and then remove the multi-app configuration once the number of users on the older version has decreased.

If we migrate to multiple App Keys, we would need more than the allowed number of App Keys. How should we handle this situation?

We can grant additional registration permission so that up to 20 apps can be registered. Could you let us know the app ID to which the permission should be granted?

beiyuanjing5890 · 5월 12, 2026, 8:56오전

Thanks for your response. May I know：

After the multi-app feature is deprecated and after grace period ：

What will happen to applications that were previously configured under multi-app and have not migrated to multiple native app keys? Will the login action fail with specific error message, or some other weird actions? I’d like to know this because not all users will upgrade tiktok to newest version with native app keys.
Yes, We need over 5 app keys for kakao app id 127105(TikTok),could you help to grant additional registration permission for 127105?

tim.l · 5월 12, 2026, 10:21오전

Hello

An additional grace period can be provided for services that have completed the migration.
Additional registration permissions have been granted, allowing up to 20 registrations.

Thank you

beiyuanjing5890 · 5월 12, 2026, 6:26오후

Thanks for your response.

I also want to know what will happen to applications that were previously configured under multi-app and have not migrated to multiple native app keys after grace period?Will the oauth login action fail with specific error message, or some other weird actions, or an additional grace period will be added automatically to ensure availability if there still some traffic under multi-app? I’d like to know this because not all users will upgrade tiktok to newest version with native app keys and there will be long-tail traffic. We want to know what’s the impact and what Tiktok should do to notify user about the upgrade, like force upgrade or just ignore the traffic.

tim.l · 5월 13, 2026, 1:28오전

The multi-app termination will proceed as scheduled, and configuration will no longer be available afterward.

However, for services that have completed migration deployment, requests using legacy multi-app keys will be allowed for one year.

After one year, we will review the trend of legacy-version users and determine whether an additional extension is needed to minimize impact on the services you operate.

beiyuanjing5890 · 5월 14, 2026, 9:06오후

Thanks for your response.

“for services that have completed migration deployment, requests using legacy multi-app keys will be allowed for one year.“ Is it automatically? or we should request for that?
We have a native app key binding with package_name_1 and bundle_id_1, and it also binds with multi package name(package_name_2,package_name_3) and multi bundle id(bundle_id_2,bundle_id_3).
1. Should we create new native app key for package_name_1 and bundle_id_1 and remove the configuration only?
2. Or we just need to create new native app key for multi-all(package_name_2,package_name_3,bundle_id_2,bundle_id_3) , remove multi-app configuration and just leave package_name_1 and bundle_id_1 as they are?

tim.l · 5월 15, 2026, 1:29오전

Hello,

Could you please briefly apply and share this in the current text?
(Policy application will be carried out in a way that minimizes user inconvenience, so we do not plan to block anything without communicating with the service owner.)
Since users on older versions also need to use it, please keep the existing settings as well.

Thank you.