Skip to main content
The Embedded Wallet APIs enable end users to directly create, manage, and use their accounts. They are typically accessed via the CDP Web SDK. End users authenticate with the APIs via the InitiateAuthentication endpoint, and use the returned access token and refresh token to authenticate with the other endpoints. The Embedded Wallet APIs offer end users full control over their accounts, including the ability to sign transactions and messages, and to export their accounts’ private keys. There are three authentication credentials involved in the Embedded Wallet APIs:
  1. Access Token: A JWT signed by CDP, encoded in base64. This is used to identify the end user, and is issued after the end user has signed in using one of the provided authentication methods. The APIs provide multiple mechanisms for end user authentication, including custom auth JWT authentication, email one-time-password (OTP) authentication, and social sign-in.
  2. Refresh Token: A cryptographically random string, set as the cdp_refresh_token cookie in the end user’s browser. By hitting the RefreshAccessToken endpoint, the included refresh token can be used to obtain a new access token without requiring the end user to sign in again.
  3. Temporary Wallet Secret (TWS): Requests to signing-related endpoints must also be authenticated using a Temporary Wallet Secret (TWS) generated on the end user’s browser/device. Typically, this is done using the CDP Embedded Wallet SDK. The Temporary Wallet Secret follows similar semantics to the Wallet Secret used by the EVM and Solana Account APIs, with the following key differences:
  • The end user must register their TWS with the End User Accounts APIs before it can be used.
  • Temporary Wallet Secrets have a time-to-live (TTL) defined by the validUntil field in the TWS registration request.
  • A maximum of five TWS’s can be registered for a single end user at any given time.

​
Delegated Signing

Delegated signing allows developers to sign and send transactions on behalf of an end user without requiring the end user to be present at signing time. This is useful for background operations, automated workflows, and scenarios where the developer’s server needs to act on the end user’s behalf. To use delegated signing, the end user must first create a short-lived delegation grant by authenticating with their access token and Temporary Wallet Secret. The grant specifies an expiresAt timestamp that defines how long the developer is authorized to sign on the end user’s behalf. Once a delegation grant is active, the developer’s server can use its CDP API key to perform signing operations for that end user. The delegation middleware transparently validates that an active (non-expired, non-revoked) grant exists for the pair before allowing the operation to proceed. Grant lifecycle:
  • Delegation grants are scoped to a single project and end user pair.
  • Grants are time-bounded by the expiresAt timestamp and are automatically cleaned up after expiration.
  • Grants can be revoked early by either the end user (using their access token and TWS) or the developer (using their API key), via the RevokeDelegationForEndUser endpoint.
  • Only one active grant can exist per pair at a given time.