5f3dd98
Author @amircheikh - Added name
field to constructor. isHttpClient
now uses this new field to complete the check. This fixes a bug where isHttpClient
would fail the check under certain production environments.
Synced with mono 2025.6.10 to include the following endpoints:
update_user_email
: Update a User’s email in an existing Organization
update_user_name
: Update a User’s name in an existing Organization
update_user_phone_number
: Update a User’s phone number in an existing Organization
7625df0
]:
be0a621
Author @amircheikh - Exposed isHttpClient
function for determining if a passed in client is from turnkey/http593de2d
Thanks @moe-dev! - Update to endpoints as per mono v2025.5.7. Add V5 TON address format generation. Non breaking
5afbe51
, 40c4035
]:
0x...
). If you also wanted the public key associated with that underlying key, you would’ve had to derive an additional wallet account with ADDRESS_FORMAT_COMPRESSED
. Now, this will automatically be derived for you. It is now a property that has been added to the wallet account primitive (i.e. accessible via walletAccount.publicKey
).INIT_OTP_AUTH_V2
which allows alphanumeric boolean and otpLength (6-9) to be passed
INIT_OTP_AUTH_V2
activity. The difference between it and INIT_OTP_AUTH
is that it can now accept alphanumeric
and otpLength
for selecting crockford bech32 alphanumeric codes and the length of those codes. By default alphanumeric = true, otpLength = 9
sendFromEmailSenderName
to INIT_OTP_AUTH
, INIT_OTP_AUTH_V2
, EMAIL_AUTH
and EMAIL_AUTH_V2
. This is an optional custom sender name for use with sendFromEmailAddress; if left empty, will default to ‘Notifications’.
CREATE_USERS_V3
activity. The difference between it and CREATE_USERS_V2
is that it can now accept userPhoneNumber
and oauthProviders
. In total, it accepts the following parameters:invalidateExisting
flag to the CreateReadWriteSession
and Oauth
activities. If enabled, this will invalidate existing read-write and oauth API keys. This is useful in scenarios where a user attempts to create numerous ReadWrite
or Oauth
sessions. Because our API caps the number of session keys associated with a user, this flag can clear all other existing session keys of that specific type (e.g. setting invalidateExisting: true
for CreateReadWriteSession
will invalidate all previously created read-write session keys)GetWalletAccount
. This endpoint takes in the following args:
getSignatureFromActivity
returns the signature corresponding to a completed activitygetSignedTransactionFromActivity
returns the signed transaction corresponding to a completed activityassertActivityCompleted
checks the state of an activity and throws an error if the activity either requires consensus or is otherwise not yet completedTERMINAL_ACTIVITY_STATUSES
is a const containing all terminal activity statuses. Useful for checking on an activityTurnkeyActivityError
now uses undefined
instead of null
TActivity
, TActivityId
, TActivityStatus
, TActivityType
mnemonicLength
is now a number instead of a string@turnkey/encoding
to consolidate utility functionsexpirationSeconds
parameter.require
. Use ES6 imports instead (#178)/public/v1/query/list_wallets
)/public/v1/query/list_wallet_accounts
)signRawPayload
and signTransaction
now expect a signWith
param instead of privateKeyId
previouslysignRawPayload
and signTransaction
have been updated to expect a new type: ACTIVITY_TYPE_SIGN_RAW_PAYLOAD_V2
and ACTIVITY_TYPE_SIGN_TRANSACTION_V2
, respectivelyACTIVITY_TYPE_SIGN_RAW_PAYLOAD
or ACTIVITY_TYPE_SIGN_TRANSACTION
specifically, they will need to be updated to authorize ACTIVITY_TYPE_SIGN_RAW_PAYLOAD_V2
and ACTIVITY_TYPE_SIGN_TRANSACTION_V2
(or better yet, update your policies to allow all signing actions categorically using policy resources and actions. See https://docs.turnkey.com/managing-policies/examples)createSubOrganization
now uses ACTIVITY_TYPE_CREATE_SUB_ORGANIZATION_V4
under the hood, which utilizes wallets. The shape of the request has been updated to include the following parameter, wallet
. Here’s an example:ACTIVITY_TYPE_CREATE_WALLET
(via /api/v1/submit/create_wallet
): create a HD walletACTIVITY_TYPE_CREATE_WALLET_ACCOUNTS
(via /api/v1/submit/create_wallet_accounts
): create a wallet account (address)ACTIVITY_TYPE_SIGN_RAW_PAYLOAD_V2
(via /api/v1/submit/sign_raw_payload_v2
): sign a payload with a specified private key or addressACTIVITY_TYPE_SIGN_TRANSACTION_V2
(via /api/v1/submit/sign_transaction_v2
): sign a transaction with a specified private key or addressACTIVITY_TYPE_SET_ORGANIZATION_FEATURE
(via /api/v1/submit/set_organization_feature
): set an organization featureACTIVITY_TYPE_REMOVE_ORGANIZATION_FEATURE
(via /api/v1/submit/remove_organization_feature
): remove an organization featureACTIVITY_TYPE_EXPORT_PRIVATE_KEY
(via /api/v1/submit/export_private_key
): export a private key, encrypted to a target public key. We do not yet have CLI or front-end tooling to use this safely; stay tuned!ACTIVITY_TYPE_INIT_USER_EMAIL_RECOVERY
(via /api/v1/submit/init_user_email_recovery
): initialize a new email recovery flowcreateSubOrganization
request has been updated under the hood:
.createSubOrganization
on our HTTP client will trigger an activity of type CREATE_SUB_ORGANIZATION_V3
instead of CREATE_SUB_ORGANIZATION_V2
previously.CREATE_SUB_ORGANIZATION_V2
specifically, they will no longer work out of the box if creating sub-orgs via SDK. These policies will need to be updated to allow CREATE_SUB_ORGANIZATION_V3
. See policy examples related to access control here for additional methods of constructing policies.CREATE_SUB_ORGANIZATION_V3
supports everything CREATE_SUB_ORGANIZATION_V2
supports, with the addition of a privateKeys
field to atomically create a sub-org with private keys. If no private keys are desired, simply provide an empty array.createSubOrganization
results, SDK users will now need to look at activity.result.createSubOrganizationResultV3
instead of the previously valid activity.result.createSubOrganizationResult
.TurnkeyClient
. This is now the preferred interface to make Turnkey requests, because it supports both API keys and webauthn-signed requests. It also doesn’t rely on global initializationcreateActivityPoller
TurnkeyApi
(use TurnkeyClient
instead), init
, browserInit
(no need for them anymore if you’re using TurnkeyClient
), and withAsyncPolling
(use createActivityPoller
instead)SignedRequest
in favor of TSignedRequest
. Besides the more correct name, TSignedRequest
differs in its stamp
property. It now stores the stamper header name as well as value, so users do not have to hardcode Turnkey stamp header names (e.g. “X-Stamp-Webauthn”)./public/v1/submit/update_user
limit
option has been updated to string
instead of number for consistency with other pagination optionsuseGetGetActivity
is now useGetActivity
, and usePostSignTransaction
is useSignTransaction
.TPostCreatePrivateKeysInput
is now TCreatePrivateKeysInput
.0.18.0
are now named “signed” requests to better reflect what they are. FederatedRequest
is now SignedRequest
, and generated types follow. For example: federatedPostCreatePrivateKeys
is now signCreatePrivateKeys
, federatedGetGetActivity
is now signGetActivity
, and so on.sdk/examples/with-federated-passkeys
)/submit/approve_activity
, /submit/reject_activity
)/submit/create_authenticators
)/submit/update_private_key_tag
)/submit/update_user_tag
)AuthenticatorParams
with a new AuthenticatorParamsV2
. To take advantage of this new shape, use ACTIVITY_TYPE_CREATE_USERS_V2
and the new ACTIVITY_TYPE_CREATE_AUTHENTICATORS
..postGetPrivateKey(...)
’s underlying path, while adding @deprecated
.postGetPrivateKeyBackwardsCompat(...)
for backward compatibilitysealAndStampRequestBody(...)
.addressFormats
enum field in /submit/create_private_keys
TurnkeyRequestError
error class that contains rich error details/submit/create_api_only_users
endpoint: TurnkeyApi.postCreateApiOnlyUsers(...)
TurnkeyApi.postCreateUsers(...)
as deprecated/submit/create_users
endpoint: TurnkeyApi.postCreateUsers(...)
undici
to cross-fetch
to improve bundler compatibility@turnkey/http
is now a universal (isomorphic) packageTurnkeyApi
. PublicApiService
has been marked as deprecated, but will remain functional until we hit v1.0.withAsyncPolling(...)
helper to provide built-in async polling support. Read more:
timestamp
-> timestampMs
keyId
-> privateKeyId
everywherekeyId
to privateKeyId