Native project transfer: recipient binding and protected Preview continuity

Hello Vercel team,

We are assessing a synthetic two-team lab before activating paid service. The intended workflow is a protected Preview deployment followed by native project transfer with explicit recipient acceptance. No customer data or live transfer is involved yet.

We have reviewed: https://vercel.com/docs/rest-api/projects/create-project-transfer-request

vercel.com

Create project transfer request | Vercel REST API

Initiates a project transfer request from one team to another. <br/> Returns a `code` that remains valid for 24 hours and can be used to accept the transfer request by another team using the `PUT /projects/transfer-request/:code` endpoint. <br/> Users can also accept the project transfer request using the claim URL: `https://vercel.com/claim-deployment?code=<code>&returnUrl=<returnUrl>`. <br/> The `code` parameter specifies the project transfer request code generated using this endpoint. <br/> The `returnUrl` parameter redirects users to a specific page of the application if the claim URL is invalid or expired.

https://vercel.com/docs/rest-api/projects/accept-project-transfer-request https://vercel.com/docs/projects/transferring-projects https://vercel.com/docs/deployment-protection

Could you clarify four platform behaviors?

TRANSFER AUTHORIZATION AND RECIPIENT BINDING

For POST /projects/{idOrName}/transfer-request and PUT /projects/transfer-request/{code}, which token types, minimum scopes, and source/recipient roles are supported?

Can the source bind the request to a specific immutable destination team ID before acceptance?

If not, please confirm what prevents another eligible team from accepting a disclosed claim code outside our application's acceptance path, and whether a supported native alternative preserves explicit recipient acceptance with a source-selected destination.

Please also clarify single-use/replay behavior, cancellation, and whether creating a new request invalidates an earlier unaccepted code.

PROTECTED PREVIEW WITHOUT PUBLICATION

For an empty project, what exact project settings and deployment REST payload produce only a protected Preview, without unintentionally publishing content through production domains or aliases?

We intend to disable automatic Git deployments and prohibit production deployment/promotion. Please distinguish those application controls from provider-enforced restrictions.

Is Standard Vercel Authentication sufficient for this restricted workflow? Please identify any additional plan or protection feature actually needed.

PROTECTION CONTINUITY DURING TRANSFER

Does the request/accept transfer preserve authentication protection continuously across all existing deployment URLs and aliases?

What happens to previously authenticated sessions, source-team access, recipient-team access, and protection configuration during and immediately after the transfer? Which settings require explicit readback or reconfiguration before access is safe?

AMBIGUOUS RESULTS AND RECOVERY

After an acceptance timeout, lost response, or partially reported result, which authoritative endpoint/state establishes the project's current owner and whether the transfer completed?

What is the safe retry/idempotency behavior? Which failed or pending transfers can be cancelled? Does reversing a completed transfer require a newly authorized transfer and recipient cooperation?

Please link current documentation or provide minimal supported request/ response examples. Where the requested guarantee is not supported, a clear statement and supported alternative would help us avoid building against an incorrect assumption.

We are requesting capability clarification only, not account changes, provisioning, paid support, or an upgrade.