Cloud ID 사용자 초대 API를 사용하면 Google Workspace 또는 Cloud ID 도메인에 대한 온보딩 사용자의 일부인 비관리 계정을 식별하고 관리할 수 있습니다.
비관리 계정은 다음 기준으로 정의됩니다.
이메일 주소가 일반 계정이고 계정의 기본 이메일 주소입니다.
이메일 주소의 도메인이 기존 확인된 Google Workspace 또는 Cloud ID 도메인과 일치합니다.
일반적으로 이러한 계정은 고객의 사용자 중 한 명이 직장 이메일 주소 또는 사용자 안내 이메일 주소를 사용하여 일반 사용자용 Google 서비스에 가입했기 때문에 존재합니다.
고객이 Google Workspace 또는 Cloud ID에 가입하고 기존 비관리 계정과 동일한 기본 이메일 주소로 사용자 계정을 프로비저닝하면 비관리 계정이 중복되므로 이 문제를 해결해야 합니다.
사용자 초대 API를 사용하면 주요 해상도 작업이 자동으로 업데이트됩니다.
지정된 이메일 주소가 고객의 도메인에 참여할 수 있는지 확인합니다(두 조건을 모두 충족해야 함).
고객의 도메인에 가입할 수 있도록 자격 요건을 충족하는 이메일 주소에 임시 또는 일괄 이메일 초대장을 보냅니다.
초대 상태로 필터링할 수 있는 비관리 계정의 목록을 가져옵니다. 고객 도메인의 모든 비관리 계정은 전송될 때까지 전송되지 않은 사용자 초대(state==NOT_YET_SENT)로 취급됩니다.
이메일 주소로 특정 초대 검색하기
이미 보낸 초대 취소
사용자 초대 흐름을 사용하면 최종 사용자와 관리자 모두가 일반 계정을 사용하여 만든 모든 데이터가 올바른 항목에서 관리되도록 할 수 있습니다.
일반 계정에 비즈니스 관련 데이터가 있는 최종 사용자가 초대를 수락하면 관리자가 고객 정책에 따라 소유권을 가져와 데이터를 관리할 수 있습니다.
최종 사용자의 데이터가 비즈니스와 관련이 없고 최종 사용자가 거부하는 경우, 초대에서 나중에 관리자가 사용자를 위한 새 Google 계정을 만드는 경우 이메일 주소의 이름을 바꿔야 할 수도 있음을 사용자에게 알립니다. 관리자가 새 관리 계정을 만들고 일반 계정의 기본 이메일 주소를 제거하면 충돌이 발생할 수 있습니다. 그러면 최종 사용자가 개인 Google 계정에 로그인할 때마다 이메일 주소를 다른 이메일 주소로 변경하라는 메시지가 표시됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eThe Cloud Identity User Invitation API helps manage unmanaged accounts during user onboarding to Google Workspace or Cloud Identity domains.\u003c/p\u003e\n"],["\u003cp\u003eUnmanaged accounts are consumer accounts whose email domain matches a verified Google Workspace or Cloud Identity domain, created because users signed up for consumer Google services with their work or school email.\u003c/p\u003e\n"],["\u003cp\u003eThis API automates key resolution tasks, like determining eligibility, sending invitations, listing unmanaged accounts, looking up specific invitations, and canceling sent invitations.\u003c/p\u003e\n"],["\u003cp\u003eThe user invitation process allows administrators to take ownership of business-related data from consumer accounts or inform users to rename their email if it's personal.\u003c/p\u003e\n"],["\u003cp\u003eThe API can be set up by following the steps in \u003ca href=\"/identity/docs/how-to/setup-user-invitations\"\u003eSetting up the User Invitation API\u003c/a\u003e, and more information on conflict resolution can be found in the Google Admin Help Center under \u003ca href=\"https://support.google.com/a/answer/6178640\"\u003eFind and manage existing accounts\u003c/a\u003e.\u003c/p\u003e\n"]]],[],null,["# User Invitation API overview\n============================\n\nThe Cloud Identity User Invitation API allows you to identify and manage\nunmanaged accounts as part of onboarding users to your Google Workspace or\nCloud Identity domain.\n|\n| **Beta**\n|\n|\n| This product is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA products are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nUnmanaged accounts are defined by the following criteria:\n\n- the email address is a consumer account and it's the primary email address of the account, and\n- the domain of the email address matches an existing verified Google Workspace or Cloud Identity domain\n\nThese accounts generally exist because one of the customer's users has signed\nup for consumer Google services using their work or educational email address.\nWhen the customer then signs up for Google Workspace or Cloud Identity\nand provisions a user account with the same primary email address as an\nexisting unmanaged account, that unmanaged account becomes conflicted and\nneeds to be resolved.\n\nThe User Invitation API makes key resolution tasks automatable:\n\n- Determine if a given email address is eligible to join the customer's domain (must meet both criteria)\n- Send ad-hoc or batch email invitations to eligible email addresses so they can join the customer's domain\n- Retrieve a list of unmanaged accounts, filterable by their invitation state. All unmanaged accounts on the customer's domain are treated as unsent user invitations (`state==NOT_YET_SENT`) until they are sent.\n- Look up a specific invitation by email address\n- Cancel already-sent invitations\n\nThe user invitation flow allows both the end user and the administrator to\nensure that any data created using the consumer account is managed by the\ncorrect entity:\n\n- If the end user has business-related data under the consumer account and accepts the invitation, the administrator can take ownership and manage the data according to the customer's policies.\n- If the end user's data is not business-related and they decline, the invitation gives the user notice that they may need to rename the email address later if the admin creates a new Google account for them. The administrator can create a new managed account and evict the primary email address of the consumer account, creating the conflict. The end user will then be asked to rename their email address to another email address every time they log in to their personal Google account.\n\nNext steps\n----------\n\nHere are a few next steps you might take:\n\n- To set up the API, refer to [Setting up the User Invitation API](/identity/docs/how-to/setup-user-invitations).\n- To understand how account conflict resolution works in the Admin Console, read [Find and manage existing accounts](https://support.google.com/a/answer/6178640) in the Google Admin Help Center."]]
