paginationOptions field
-paginationOptions field
-
-
-
-## Next steps
-
-Dig into Company Wallet features like multichain support, scoped API keys, multi-signature approvals, and [more](/products/company-wallets/features/multi-chain-support).
diff --git a/concepts/broadcasting.mdx b/concepts/broadcasting.mdx
deleted file mode 100644
index 4dc1084d..00000000
--- a/concepts/broadcasting.mdx
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: "Broadcasting"
-description: "Transaction construction, broadcast, and status monitoring for EVM and Solana."
----
-
-## Construction and Broadcast
-
-### EVM
-
-A successful EVM transaction requires:
-
-- **Transaction construction**: assembling the payload (recipient, value, calldata)
-- **Nonce**: set correctly to order transactions and prevent conflicts
-- **Gas and tip fee**: estimated to ensure inclusion even during network congestion
-- **Signature**: cryptographically signing the transaction with the sender's private key
-- **Broadcast**: submitting the signed transaction to the network and monitoring for inclusion
-
-Turnkey handles all of this for you via `ethSendTransaction`. Whether or not you use sponsorship, you pass through minimal payloads and we take care of the rest. We auto-fill any fields you omit.
-
-This endpoint supports arbitrary EVM transactions — not just simple sends. You can interact with smart contracts, deploy contracts, or execute any valid EVM operation.
-
-### Solana
-
-A successful Solana transaction requires:
-
-- **Transaction construction**: assembling the list of instructions (program, accounts, data)
-- **Recent blockhash**: fetched and attached at broadcast time to ensure the transaction is valid
-- **Compute unit limit**: estimated and set to prevent failed transactions due to insufficient compute
-- **Priority fee**: set to ensure timely inclusion under current network conditions
-- **Signature**: cryptographically signing the transaction with the sender's private key
-- **Broadcast**: submitting the signed transaction to the network and monitoring for confirmation
-
-Turnkey handles all of this for you via `solSendTransaction`. Whether or not you use sponsorship, you pass through a minimal payload and we manage the rest.
-
-
-
-
-- **Organizations (parent orgs)** in Turnkey are top-level entities that contain users, wallets, and policies for a business, with the initial “parent organization” typically representing an entire Turnkey-powered application.
-- Parent organizations can create **sub-organizations (sub-orgs)**, which are fully segregated organizations nested under the parent organization. Parent orgs cannot modify the contents of a sub-org, and sub-orgs typically represent an end user.
-- Both parent organizations and sub-organizations contain a set of **resources and authenticators** that you can configure, including their own users, wallets, API keys, private keys, and policies.
-- **Activities** (like signing transactions or creating users) are governed by **policies** created via Turnkey’s policy engine, though root users can bypass the policy engine when meeting root quorum requirements.
-- **Wallets** in Turnkey are HD seed phrases that can generate multiple wallet accounts (addresses) for signing operations.
-
-### Managing Turnkey interactions and organizations
-
-There are two primary ways for users to interact with Turnkey — via the Turnkey Dashboard, and by submitting activity requests via our public API.
-
-The Turnkey Dashboard, which is where you’ll first create your Turnkey parent organization, is where root users of your parent organization will typically manage administrative activities. It supports passkey authentication only.
-
-On the other hand, interactions with Turnkey at scale (primarily, interactions initiated by end users) can be done via programmatically calling the Turnkey public API and submitting activity requests, with a variety of authentication methods supported.
-
-## Concepts dictionary
-
-For more details on individual concepts, feel free to explore our concept-specific documentation (also accessible through the left navbar).
-
-### Organizations
-
-An organization is a logical grouping of resources like users, policies, and wallets. There are two types of organizations:
-
-| Organization type | Description |
-| :------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Parent Organization | When you first setup your implementation of Turnkey by signing up on the dashboard you create a parent organization controlled by your business. In most implementations, a top-level organization represents an entire Turnkey-powered implementation. For more information on Turnkey parent organizations [look here](/concepts/organizations). |
-| Sub-Organization | A fully segregated organization nested under the parent organization. Parent organizations have read access to all their sub-organizations, but do not have write access. Each sub-organization typically maps to an individual end user in a Turnkey-powered application. Parent organizations can initiate limited actions for sub-organizations that then must be completed by the sub-organization (e.g. `INIT_OTP`). For more information on Turnkey sub-organizations [look here](/concepts/sub-organizations). |
-
-### Users
-
-Turnkey users are resources within organizations or sub-organizations that can submit activities to Turnkey via a valid credential (e.g., API key, passkey). These requests can be made either by making direct API calls or through the Turnkey Dashboard. Users must be set up to authenticate to Turnkey with credentials (API keys, passkeys), or via other authentication methods such as OAuth, or email auth, with upper limits on credentials defined here in our [resource limits](/concepts/resource-limits). Users can also have associated “tags” which are logical groupings that can be referenced in policies. Users can only submit activities within their given organization — they cannot take action across organizations.
-
-There are two main types of users:
-
-| User type | Description |
-| :----------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Root Users | The first user(s) created in an organization will have root permissions, meaning they can bypass the policy engine to take any action within that specific organization. This ability can be limited via root quorum, which requires a threshold of root users to access root permissions. For example, if there are five root users and the threshold is three, at least three users must approve an activity for the root quorum threshold to be reached. When you first create a Turnkey organization, your user is automatically created as the sole member of the root quorum by default. |
-| Normal Users | Other than managing their own credentials, non-root users have no permissions unless explicitly granted by [policies](/concepts/policies/overview). By combining non-root users with policies granting permission for specific actions, you can build support for experiences providing [delegated access](/concepts/policies/delegated-access) to business controlled service account. |
-
-In parent organizations, a user often maps to an individual from your team with administrative privileges and responsibilities. In sub-organizations, which are often used to manage an end user's resources, a user can represent an end user and their credentials. If there is only one user representing the end user with only end-user controlled credentials then this would be more akin to a standard non-custodial setup. However, this flexible primitive can often represent other aspects of your backend or application. For example, a Turnkey user might map to a:
-
-- Backend service used to automate certain transactions
-- Service with delegated access to take action on behalf of an end user
-- Required co-signer for all end user transactions
-
-For more information on Turnkey users [look here](/concepts/users/introduction).
-
-### Credentials
-
-Interacting with the Turnkey API requires each API call to be authenticated by cryptographically stamping it with a credential. This process is abstracted away in our SDKs and ensures that the request cannot be tampered with as it travels to the secure enclave. Credentials include API keys and passkeys / Webauthn devices for all Users, while sub-organization users can also use email or OAuth to authenticate. Email and OAuth leverage API keys under the hood.
-
-For more information on Turnkey user credentials [look here](/concepts/users/credentials).
-
-### Activities
-
-Activities are specific actions taken by users, such as signing a transaction, adding a new user, or creating a sub-organization. Activity requests are always evaluated through our policy engine, and can evaluate to ALLOW, DENY, or REQUIRES_CONSENSUS (i.e., requires additional approvals before being allowed).
-
-For more information on Turnkey activities [look here](/developer-reference/api-overview/submissions).
-
-### Policies
-
-Policies, enforced by Turnkey’s policy engine, grant users permissions to perform activities. These policies are a series of logical statements (e.g., User ID == 123 or ETH address == 0x543…9b34) that evaluate to either “ALLOW” or “DENY.” Through these policies you can set granular controls on which users can take which actions with which wallets. Policies can also require multi-party approval / consensus, meaning a threshold of certain users will be required to approve the activity. As mentioned above, the root quorum will bypass the policy engine.
-
-For more information on Turnkey policies [look here](/concepts/policies/overview).
-
-### Wallets and private keys
-
-Resources used to generate crypto addresses and sign transactions or messages. We currently support secp256k1, ed25519, and P256 curves and have two main types:
-
-| Resource type | Description |
-| :------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Wallets (preferred) | A hierarchical deterministic (HD) wallet, which is a collection of cryptographic key pairs derived from a common seed phrase. A wallet (i.e., a single seed phrase) can have many wallet accounts (i.e., a set of derived addresses). Wallets support various cryptographic curves and can be represented by a checksummed mnemonic phrase, making them easier to back up and recover. We limit each organization to 100 Wallets, but there is no limit on the total number of wallet accounts. For more information on Turnkey HD wallets [look here](/concepts/wallets). |
-| Private Keys | Raw private keys represented by an alphanumeric string. We limit each organization to 1,000 private keys, therefore we recommend using wallets instead of private keys for better scalability. |
-
-Learn more about leveraging Wallets across different crypto ecosystems on our [Ecosystem Support](/networks/overview) page.
-
--> Head over to [SDK Reference](https://docs.turnkey.com/generated-docs/formatted/react-wallet-kit/client-context-type-add-passkey) for the updated packages. - -### Initialize the Passkey client - -Begin by initializing the Turnkey SDK by passing in a config object containing: - -* `rpId`: The [Relying Party](https://developer.mozilla.org/en-US/docs/Glossary/Relying_party) Identifier, which is the effective domain of your application. -* `apiBaseUrl`: The base URL of the Turnkey API: `https://api.turnkey.com` -* `defaultOrganizationId`: Your parent organization ID, which you can find in the [Turnkey dashboard](https://app.turnkey.com/dashboard). - -
{/* We'll add UI elements here */}
;
-}
-```
-
-
-
- );
-}
-```
-
-
-
- );
-}
-```
-
- {/* Add a button to add the passkey to the wallet */}
-
-
-
- );
- }
- ```
-
-
-
-
- );
-}
- ```
--> Head over to [SDK Reference](https://docs.turnkey.com/sdks/react/auth) for the updated packages. - -
-> Head over to [SDK Reference](https://docs.turnkey.com/sdks/react/sub-organization-customization) for the updated packages. - -
-> Head over to [SDK Reference](https://docs.turnkey.com/generated-docs/formatted/react-wallet-kit/client-context-type-login-with-passkey) for the updated packages. - -By calling `loginWithPasskey()`, the SDK stores the session and active client in localStorage. The signing key material remains securely stored in the browser’s IndexedDB and is never extractable. Turnkey uses this public key to scope and encrypt the session to the appropriate user. - -## Steps using `@turnkey/sdk-react` - -This process is made seamless by leveraging our [React package](/sdks/react). Read on for a non-React implementation below. - -
-
- {/* Your app components */}
-
-
-```
-
--> Head over to [SDK Reference](https://docs.turnkey.com/sdks/react/sub-organization-customization) for the updated packages. - -## Overview - -Generally, these new users will take the form of a [Turnkey Sub-Organization](/concepts/sub-organizations). This process involves using the following Turnkey SDK packages: - -1. [`@turnkey/sdk-server`](https://www.npmjs.com/package/@turnkey/sdk-server): Used on the server-side to leverage the parent organization's public/private API key pair to create the new user's sub-organization. -2. [`@turnkey/sdk-browser`](https://www.npmjs.com/package/@turnkey/sdk-browser): Used on the client-side to complete the email recovery process by adding an end-user passkey. -3. [`@turnkey/sdk-react`](https://www.npmjs.com/package/@turnkey/sdk-react): Used for Next.js applications to initialize the Turnkey SDK. - -The process of creating a new sub-organization is split between client-side and server-side operations to prevent exposing the parent organization's private API key. - -
{/* ... rest of the code */}
;
-}
-```
-
-
- {createSubOrganizationResponse ? (
-
- );
- }
- ```
- You've created a sub-organization!
- ) : ( - - )} -
- {createSubOrganizationResponse ? (
-
- );
- }
- ```
- You've created a sub-organization!
- ) : ( - - )} --> Head over to [SDK Reference](https://docs.turnkey.com/sdks/react/sub-organization-customization) for the updated packages. - -
{/* ... rest of the code */}
;
-}
-```
-
- setEmail(e.target.value)}
- type="text"
- />
-
- );
-}
-```
-
- {/* */}
-
-
- );
-}
-```
-
- {/* If we have initiated the recovery process we'll render an input
- for the user to paste their credential bundle they received in their email */}
- {initRecoveryResponse ? (
- setCredentialBundle(e.target.value)}
- type="text"
- />
- ) : (
- setEmail(e.target.value)}
- type="text"
- />
- )}
-
-
- );
-}
-```
-
-
- {/* If we have initiated the recovery process we'll render an input
- for the user to paste their credential bundle they received in their email */}
- {initRecoveryResponse ? (
- setCredentialBundle(e.target.value)}
- type="text"
- />
- ) : (
- setEmail(e.target.value)}
- type="text"
- />
- )}
-
-
- );
-}
- ```
-{/* ... */}
;
-}
-```
-
- {/* ... */}
-
- {/* If we have the credential bundle, we'll render a button to complete the recovery process */}
- {credentialBundle ? (
-
- ) : (
-
- )}
-
- );
-}
-```
-
- {/* ... */}
-
- {/* If we have the credential bundle, we'll render a button to complete the recovery process */}
- {credentialBundle ? (
-
- ) : (
-
- )}
-
- );
-}
-```
-
- {initRecoveryResponse ? (
- setCredentialBundle(e.target.value)}
- type="text"
- />
- ) : (
- setEmail(e.target.value)}
- type="text"
- />
- )}
- {credentialBundle ? (
-
- ) : (
-
- )}
-
- );
-}
- ```
--> Head over to [SDK Reference](/sdks/react/using-embedded-wallets#importing-and-exporting-wallets) for the updated packages. - -## Implementation guides - -Follow along with the Turnkey CLI, Embedded iframe, NodeJS, and Local Storage guides. - -### CLI - -Install the latest version of Turnkey CLI to access the new import functionality. You can find detailed instructions for installation [here](https://github.com/tkhq/tkcli). - -#### Steps - -
-
-
-Let's review these steps in detail:
-
-
-
-
-The exported wallet will remain stored within Turnkey’s infrastructure. In your Turnkey dashboard, the exported user Wallet will be flagged as “Exported”.
-
-
-
-
-At the end of a successful private key export, the iframe displays a private key.
-
-### NodeJS
-
-A full example Node script can be found here: [https://github.com/tkhq/sdk/tree/main/examples/export-in-node](https://github.com/tkhq/sdk/tree/main/examples/export-in-node)
-
-#### Steps
-
-
-
-
-);
-```
-
-## Solana notes
-
-Solana paths do not include an `index`. Creating a wallet account with an index specified could lead to unexpected behavior when exporting and importing into another wallet.
-
-When importing into a multichain wallet such as Phantom, see [this guide](https://help.phantom.app/hc/en-us/articles/12988493966227-What-derivation-paths-does-Phantom-wallet-support#:~:text=The%20addresses%20are%20grouped%20into,'%2F0'%2F0%2F0.) on matching private keys across Solana, Ethereum, and Polygon.
-
-When exporting, if you export with the `hexadecimal` format, you can easily convert to base58 (Phantom-compatible) with a script like the following:
-
-
-```javascript
-var web3 = require('@solana/web3.js')
-var bs58 = require('bs58')
-
-const uint8arrayToHexString = (buffer) => {
- return [...buffer].map((x) => x.toString(16).padStart(2, "0")).join("");
-};
-
-const uint8arrayFromHexString = (hexString) =>
- new Uint8Array(hexString.match(/../g).map((h) => parseInt(h, 16)));
-
-const privateKey = "-> Head over to [SDK Reference](/sdks/react/using-embedded-wallets#importing-and-exporting-wallets) for the updated packages. - -## Implementation guides - -Follow along with the Turnkey CLI, Embedded iframe, NodeJS, and Local Storage guides. - -### CLI - -Install the latest version of Turnkey CLI to access the new import functionality. You can find detailed instructions for installation [here](https://github.com/tkhq/tkcli). - -#### Steps - -
-
-
-);
-```
diff --git a/embedded-wallets/code-examples/signing-transactions.mdx b/embedded-wallets/code-examples/signing-transactions.mdx
deleted file mode 100644
index 3e11615b..00000000
--- a/embedded-wallets/code-examples/signing-transactions.mdx
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: "Signing transactions"
-description: "This is a guide to signing transactions in the browser context. While these snippets leverage Ethers, it can be swapped out for other signers in the Viem or Solana contexts. See [here](https://github.com/tkhq/sdk/tree/main/examples/with-eth-passkeys-galore) for an example with both Ethers and Viem in the passkey + browser context, and [here](https://github.com/tkhq/sdk/tree/main/examples/with-solana-passkeys) for a similar example with Solana."
----
-> ⚠️ **This example is outdated !**-> Head over to [SDK Reference](/sdks/react/signing) for the updated packages. - -## Steps using `@turnkey/sdk-react` - -This process is made the most seamless by leveraging our [React package](/sdks/react). Read on for a non-React implementation. - -
-
- // Rest of app ...
-
-
-```
--> Head over to [SDK Reference](https://docs.turnkey.com/sdks/react/auth#configuring-oauth) for the updated packages. - -## Using @turnkey/sdk-react - -Setting up social linking with [@turnkey/sdk-react](https://www.npmjs.com/package/@turnkey/sdk-react) using the `
-> Head over to [SDK Reference](/sdks/react/using-external-wallets/overview) for the updated packages. - -## Initialize - -Begin by initializing the Turnkey SDK by passing in a config object containing: - -- `apiBaseUrl`: The base URL of the Turnkey API: `https://api.turnkey.com`. -- `defaultOrganizationId`: Your parent organization ID, which you can find in the [Turnkey dashboard](https://app.turnkey.com/dashboard). -- `wallet`: The wallet interface used to sign requests. In this example, we'll use the `EthereumWallet` interface. - -```ts config.ts -import { EthereumWallet } from '@turnkey/wallet-stamper'; - -export const turnkeyConfig = { - // Turnkey API base URL - apiBaseUrl: 'https://api.turnkey.com', - // Your parent organization ID - defaultOrganizationId: process.env.NEXT_PUBLIC_ORGANIZATION_ID!, - // The wallet interface used to sign requests - wallet: new EthereumWallet(), -}; -``` - -First, wrap your application with the `TurnkeyProvider` in your `app/layout.tsx` file. -As this file is required by Next.js to be a server component, we need to define a `TurnkeyClientProvider` client component. - -```tsx app/TurnkeyClientProvider.tsx -'use client'; - -import { TurnkeyProvider } from '@turnkey/sdk-react'; - -import { turnkeyConfig } from './config'; - -export function TurnkeyClientProvider({ - children, -}: { - children: React.ReactNode; -}) { - return
{/* We'll add UI elements here */}
;
-}
-
-````
-
-
-
-);
-}
-
-````
-
-
-
- );
-}
-```
-
-
-
-
- );
-}
-```
-
-- Turnkey Wallet Auth -
- - {/* If logged in: Show wallets */} - {session && wallets.length > 0 && ( -
-
- )}
-
- {/* If not logged in: Show Sign In */}
- {walletClient && !session && (
-
- )}
- 🧾 Wallets
- {wallets.map((wallet) => ( -
-
- ))}
-
- {wallet.walletName}
-
-
- Wallet ID: {wallet.walletId}
-
-
-
- );
-}
-```
-
-## Examples
-
-You can find examples of how to implement the above functionality using the indexedDbClient and more in the following repositories:
-
-- Turnkey Solana Wallet Auth -
- - {session && wallets.length > 0 && ( -
-
- )}
-
- {!session && (
- <>
- {!wallet.connected && 🧾 Wallets
- {wallets.map((wallet) => ( -
-
- ))}
-
- {wallet.walletName}
-
-
- Wallet ID: {wallet.walletId}
-
-
-
-
- )}
-
- )}
- 
-
-
-### Transaction Authorization Flow
-
-The sequence below describes the default funds-moving flow under the 2-of-2 root quorum model:
-
-- End user initiates a transaction from your embedded wallet UI.
-- End user approves via their authenticator (e.g., passkey). Turnkey records the activity as
- partially approved.
-- Your platform evaluates on its own backend: billing status, risk/compliance rules, and any other
- checks.
-- Your platform approves via API key and the transaction executes.
-- If the platform withholds approval, the transaction does not execute.
-
-
- 
-
-
-Relevant docs: [Activities & approvals](/concepts/overview#activities) |
-[Root quorum](/concepts/users/root-quorum)
-
-## How to Get Started on Embedded WaaS with Turnkey
-
-### Step 1: Define the Tenant Model and Ownership Boundaries
-
-Map each end user to a [Turnkey sub-organization](/concepts/sub-organizations). The standard
-approach is one sub-org per end user.
-
-- **Isolated tenants:** Each sub-org is a self-contained data boundary, with wallets, policies,
- authenticators, and activity logs fully isolated from one another.
-- **Scoped parent org permissions:** Your parent organization has read-only access to sub-orgs and
- can initiate auth and recovery flows, but cannot sign transactions or modify policies within them.
-- **External mapping:** Track the relationship between your platform's user IDs and their
- corresponding Turnkey sub-org IDs in your own database.
-
-Relevant docs: [Sub-organizations](/concepts/sub-organizations) |
-[Root quorum](/concepts/users/root-quorum)
-
-### Step 2: Design the Sub-Organization Control Model
-
-Define what lives inside each sub-org and how control is shared between your platform and the end
-user.
-
-- **End user (root):** Authenticated via passkey or equivalent user-controlled authenticator.
-- **WaaS provider (root):** Authenticated via API key. Used to approve or block transactions based
- on your service rules.
-- **Delegated Access (optional):** If needed for automation or backend-initiated workflows, add a
- scoped non-root API key via [Delegated Access](/concepts/policies/delegated-access-overview). DA
- must be tightly policy-scoped and should never have broad signing authority or bypass user
- consent.
-
-**Relevant docs:** [Delegated Access](/concepts/policies/delegated-access-overview) |
-[Policy scoping](/concepts/policies/overview)
-
-### Step 3: Define Default Wallet and Policy Template
-
-Specify what gets created in every sub-org by default: wallet structure, supported chains/accounts,
-and baseline policies.
-
-For the 2-of-2 quorum model, establish the threshold last so the backend can configure policies
-(including export) with only your platform’s approval. Start by creating a sub-org with both root
-users and wallets (Step 3a). Then, create the export policy while the platform has sole root access
-(Step 3b). Once the 2-of-2 quorum is established (Step 3c), the end user can trigger exports via
-this policy without needing your platform’s co-signature. This keeps the co-managed model
-non-custodial because end users can always export their keys and access their funds directly,
-independent of your platform.
-
-| Step | Action | Quorum State |
-| ---- | --------------------------------------------- | ------------ |
-| 3a | Create sub-org with both root users \+ wallet | 1-of-2 |
-| 3b | Create export policy for end user | 1-of-2 |
-| 3c | Update threshold to 2 | **2-of-2** |
-
-**3a. Create sub-org with both root users at 1-of-2 threshold**
-
-```javascript
-const subOrg = await turnkeyClient.createSubOrganization({
- parameters: {
- subOrganizationName: `User Wallet - ${userId}`,
- rootUsers: [
- { userName: "Platform", apiKeys: [{ publicKey: PROVIDER_KEY }] },
- {
- userName: "End User",
- authenticators: [
- {
- /* passkey */
- },
- ],
- },
- ],
- rootQuorumThreshold: 1,
- wallet: {
- walletName: "Primary Wallet",
- accounts: [
- {
- /* eth account */
- },
- ],
- },
- },
-});
-```
-
-**3b. Create export policy (user escape hatch)**
-
-```javascript
-await turnkeyClient.createPolicy({
- organizationId: subOrgId,
- parameters: {
- policyName: "Allow User Wallet Export",
- effect: "EFFECT_ALLOW",
- consensus: `approvers.any(user, user.id == '${endUserId}')`,
- condition: `activity.type == 'ACTIVITY_TYPE_EXPORT_WALLET'
- && wallet.id == '${walletId}'`,
- },
-});
-```
-
-**3c. Raise threshold to 2-of-2**
-
-```javascript
-await turnkeyClient.updateRootQuorum({
- organizationId: subOrgId,
- parameters: {
- threshold: 2,
- userIds: [providerUserId, endUserId],
- },
-});
-```
-
-Relevant docs: [Export wallets](/wallets/export-wallets) |
-[Policy examples](/concepts/policies/examples/access-control)
-
-### Step 4: Build the Developer-Facing SDK or Integration Surface
-
-Create the SDK, APIs, or UI components that downstream developers will integrate with. Abstract away
-Turnkey and expose only your platform's intended wallet, auth, and signing flows.
-
-- **Embedded Wallet Kit (EWK):** Fork or wrap [Embedded Wallet Kit](/sdks/react/index) components
- (e.g., authentication, wallet UI, and approval prompts) with your branding and surface "pending
- platform approval" states.
-- **Backend service:** Handle platform root approvals (via API key), billing and risk evaluation,
- and activity monitoring through your backend.
-- **SDK abstraction layer:** Wrap Turnkey's SDK calls behind your own interface for full control
- over the developer experience, with flexibility to swap or upgrade infrastructure without breaking
- integrations.
-
-Relevant docs: [Embedded Wallet Kit](/sdks/react/index) |
-[SDK reference](/generated-docs/react-wallet-kit/client-context-type-handle-login)
-
-### Step 5: Incorporate the Embedded Wallet into the Platform Flow
-
-Wire the wallet into your onboarding and runtime flows so every downstream integration inherits a
-working embedded wallet.
-
-- **Onboarding:** Handle Turnkey org setup, auth configuration, and the staged sub-org creation flow
- as part of your user registration. The end user should experience passkey registration (or
- equivalent) as a natural part of sign-up.
-- **Client initialization:** Initialize the Turnkey client with the user's sub-org context on each
- session. Use [sessions](/authentication/sessions) for batched signing workflows to reduce
- authentication friction during active use.
-- **Transaction flow:** Surface the approval prompt via EWK components, submit the user's approval
- to Turnkey, run your backend checks, then co-sign or withhold.
-- **Recovery:** Expose the export flow in your settings UI so users can self-serve wallet recovery.
- Turnkey's enclave encrypts the mnemonic to a user-generated target key via HPKE. Neither Turnkey
- nor your platform can view the exported material.
-
-## Use Cases
-
-| Need | Configuration |
-| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Fintech or neobank with card-linked crypto wallets | **Co-managed with billing gates:** Platform co-signs after verifying account standing. Export policy as user escape hatch. Passkey auth for consumer UX. |
-| Dev tooling platform reselling embedded wallets | **White-labeled EWK with SDK abstraction:** Downstream developers integrate with your SDK, never touching Turnkey directly. Segregated environments per end user, provider co-sign for compliance. |
-| Self-custody consumer wallet | **Self-custody model:** Maximum user sovereignty. Provider handles auth initiation and UX but has no signing authority. Application-layer controls for billing. |
-| Institutional or high-value accounts | **Co-managed with policy-based limits:** Transaction-aware policies for amount thresholds, sanctioned address deny-lists, and chain restrictions. |
-
-## The Result: Non-Custodial Control at the Infrastructure Layer
-
-Embedded WaaS with Turnkey lets you build wallets into your dev platform without owning custody or
-managing key infrastructure.
-
-- **Tenant isolation:** Isolated user wallets, credentials, and activity logs help protect end
- users’ key material and data.
-- **Quorum control:** 2-of-2 root quorum guarantees explicit user consent on every transaction.
-- **Flexible models:** Customers can evolve custody models over time as needs change.
-- **Full auditability:** Every operation is logged and nothing moves unless both the user and your
- platform approve.
-
-## DIMO Case Study
-
-[DIMO](https://dimo.co/) is a decentralized transportation network connecting over 165,000 vehicles.
-Drivers share vehicle data to access apps for insurance, fleet management, and predictive
-maintenance. DIMO uses Turnkey to power its embedded wallet infrastructure, replacing a fragmented
-onboarding flow that required external wallet apps and seed phrases.
-
-With Turnkey, DIMO delivered:
-
-- **Passkey-first onboarding:** DIMO replaced seed phrases and external wallet installs with
- Turnkey's passkey authentication, cutting sign-in time from 2 minutes to 10 seconds and boosting
- onboarding completion by 30%.
-- **Fully branded interface:** DIMO built a native auth and signing experience on an open-source
- [transactions SDK](https://github.com/DIMO-Network/transactions), powered by Turnkey’s Embedded
- WaaS passkey-based signing.
-- **Sub-org per user with full ownership:** Each driver gets an independent sub-organization, giving
- them complete control of their credentials and transactions while DIMO retains the governance
- layer needed for enterprise compliance.
-- **2-3 week integration:** DIMO deployed into their global login stack in under three weeks.
-
-Read the full case study:
-[How DIMO is bringing transportation solutions onchain with Turnkey](https://www.turnkey.com/customers/how-dimo-is-bringing-transportation-solutions-onchain-with-turnkey)
-
-## Resources
-
-- [Sub-organizations](/concepts/sub-organizations): Tenant isolation and user modeling
-- [Root quorum](/concepts/users/root-quorum): Multi-party approval and ownership configuration
-- [Policy engine](/concepts/policies/overview): Authorization rules, transaction controls, and
- export policies
-- [Embedded Wallet Kit](/reference/embedded-wallet-kit): Prebuilt UI components for auth and wallet
- flows
-- [Export wallets](/products/company-wallets/features/export-wallets): Key export and user recovery
diff --git a/embedded-wallets/features/overview.mdx b/embedded-wallets/features/overview.mdx
deleted file mode 100644
index af174bf6..00000000
--- a/embedded-wallets/features/overview.mdx
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: "Features"
-sidebarTitle: "Overview"
----
-
-
-
-
-
- 
-
-
-
-
-See [https://wallet.tx.xyz](https://wallet.tx.xyz) (and [https://github.com/tkhq/demo-embedded-wallet](https://github.com/tkhq/demo-embedded-wallet) for the code).
-
-### Demo Ethers passkeys ([code](https://github.com/tkhq/demo-ethers-passkeys))
-
-A simple application demonstrating how to create sub-organizations, create private keys, and sign with the [`@turnkey/ethers`](https://github.com/tkhq/sdk/tree/main/packages/ethers) signer, using passkeys.
-
-
- 
-
-
-See [https://github.com/tkhq/demo-ethers-passkeys](https://github.com/tkhq/demo-ethers-passkeys) for the code.
-
-### Demo Viem passkeys ([code](https://github.com/tkhq/demo-viem-passkeys))
-
-A similar, simple application demonstrating how to create sub-organizations, create private keys, and sign with the [`@turnkey/viem`](https://github.com/tkhq/sdk/tree/main/packages/viem) signer, using passkeys.
-
-
- 
-
-
-See [https://github.com/tkhq/demo-viem-passkeys](https://github.com/tkhq/demo-viem-passkeys) for the code.
-
-### Demo Viem passkeys with Gelato relay ([code](https://github.com/gelatodigital/gelato-turnkey-passkeys-relay))
-
-This example demonstrates how to leverage Turnkey’s secure key management and Gelato's battle-tested relay infrastructure to enable seamless, sponsored interactions with meta-transactions using the [`@turnkey/viem`](https://github.com/tkhq/sdk/tree/main/packages/viem) signer and [`@gelatonetwork/relay-sdk-viem`](https://github.com/gelatodigital/relay-sdk-viem).
-
-
-
- 
-
-
-
-#### How Infinex leverages Turnkey and Gelato
-
-Infinex, a platform designed to unify the decentralized ecosystem and applications under a single UX layer, eliminates the complexities of navigating fragmented crypto protocols. By integrating **Turnkey** and **Gelato**, Infinex delivers a seamless, secure, and cost-efficient experience for decentralized finance users.
-
-- **Secure Key Management with Turnkey**: Infinex ensures private keys are securely managed within Turnkey’s infrastructure, removing the need for traditional wallet pop-ups. This approach streamlines authentication through passkeys, offering a frictionless and secure user experience.
-
-- **Gasless Transactions with Gelato**: Leveraging Gelato’s Relay (ERC-2771), Infinex enables fully **sponsored transactions**, allowing users to interact with decentralized applications without ever paying gas fees. This enhances accessibility and usability, ensuring that users can participate without holding or managing native blockchain tokens for fees.
-
-The synergy between Turnkey and Gelato allows Infinex to offer an intuitive, cost-free user experience while maintaining the highest standards of security and scalability.
-
-### React Native demo app ([code](https://github.com/tkhq/react-native-demo-wallet))
-
-A React Native app that demonstrates how to use the Turnkey's JavaScript packages in a mobile environment to authenticate users, create wallets, export wallets, sign messages, and more
-
-
-
-
-See [https://github.com/tkhq/react-native-demo-wallet](https://github.com/tkhq/react-native-demo-wallet)
-for the code.
-
-### Flutter demo app ([code](https://github.com/tkhq/dart-sdk/tree/main/examples/flutter-demo-app))
-
-A Flutter app that demonstrates how to use the Turnkey's Flutter packages to authenticate users, create wallets, export wallets, sign messages, and more
-
-
-
-
-See [https://github.com/tkhq/dart-sdk/tree/main/examples/flutter-demo-app](https://github.com/tkhq/dart-sdk/tree/main/examples/flutter-demo-app)
-for the code
-
-### SDKs
-
-
-
-
-
-### Next steps
-
-Learn more about our powerful features [here](/embedded-wallets/features/overview).
diff --git a/embedded-wallets/sub-organization-auth.mdx b/embedded-wallets/sub-organization-auth.mdx
deleted file mode 100644
index a378b642..00000000
--- a/embedded-wallets/sub-organization-auth.mdx
+++ /dev/null
@@ -1,244 +0,0 @@
----
-title: "Email authentication"
-description: "Email auth is a powerful feature to couple with [sub-organizations](/concepts/sub-organizations) for your users. This approach empowers your users to authenticate their Turnkey in a simple way (via email!), while minimizing your involvement: we engineered this feature to ensure your organization is unable to take over sub-organizations even if it wanted to."
----
-
-{/* This is an internal note from Traian: this is a leftover, not referenced anywhere, we can probably delete it */}
-
-
-Our [Demo Embedded Wallet](https://wallet.tx.xyz) application serves an example of how email auth functionality might be integrated. We encourage you to try it (and check out the [code](https://github.com/tkhq/demo-embedded-wallet)) before diving into your own implementation.
-
-## Prerequisites
-
-Make sure you have set up your primary Turnkey organization with at least one API user that can programmatically initiate email auth on behalf of suborgs. Check out our [Quickstart guide](/getting-started/quickstart) if you need help getting started. To allow an API user to initiate email auth, you'll need the following policy in your main organization:
-
-```json
-{
- "effect": "EFFECT_ALLOW",
- "consensus": "approvers.any(user, user.id == '
-
-
-Let's review these steps in detail:
-
+
diff --git a/authentication/bring-your-own-auth.mdx b/features/authentication/bring-your-own-auth.mdx
similarity index 90%
rename from authentication/bring-your-own-auth.mdx
rename to features/authentication/bring-your-own-auth.mdx
index e4a4045c..79c5b972 100644
--- a/authentication/bring-your-own-auth.mdx
+++ b/features/authentication/bring-your-own-auth.mdx
@@ -70,13 +70,13 @@ After provisioning, each login follows these steps:
## Requirements for your OIDC issuer
-To use the non-custodial flow, your auth system must issue OIDC-compliant tokens with standard claims (`iss`, `sub`, `aud`, `exp`), a publicly reachable `/.well-known/openid-configuration` endpoint, and a `nonce` set to `sha256(publicKey)` to bind the token to the user's device keypair. See [OIDC token verification](/authentication/social-logins#oidc-token-verification) for the full details on how Turnkey validates tokens.
+To use the non-custodial flow, your auth system must issue OIDC-compliant tokens with standard claims (`iss`, `sub`, `aud`, `exp`), a publicly reachable `/.well-known/openid-configuration` endpoint, and a `nonce` set to `sha256(publicKey)` to bind the token to the user's device keypair. See [OIDC token verification](/features/authentication/social-logins#oidc-token-verification) for the full details on how Turnkey validates tokens.
## Integration flow
### Step 1: Register the user
-When a user first authenticates, create a Turnkey sub-org for them with your OIDC provider registered. Registration requires a valid OIDC token — Turnkey verifies its signature against your JWKS and extracts the `iss`, `sub`, and `aud` claims, storing them as the user's identity fingerprint. The token itself is not retained; on each subsequent login a fresh token is verified independently and matched against that fingerprint. See [Registration vs. login tokens](/authentication/social-logins#registration-vs-login-tokens) for the full explanation.
+When a user first authenticates, create a Turnkey sub-org for them with your OIDC provider registered. Registration requires a valid OIDC token — Turnkey verifies its signature against your JWKS and extracts the `iss`, `sub`, and `aud` claims, storing them as the user's identity fingerprint. The token itself is not retained; on each subsequent login a fresh token is verified independently and matched against that fingerprint. See [Registration vs. login tokens](/features/authentication/social-logins#registration-vs-login-tokens) for the full explanation.
```ts
await client.createSubOrganization({
@@ -131,7 +131,7 @@ export async function login({ idToken, publicKey, suborgId }) {
Turnkey's enclave verifies the token signature against your JWKS and checks the nonce matches `sha256(publicKey)`. The resulting session JWT is scoped to that public key — only the device holding the private key can use it to sign.
-If you are using `@turnkey/react-wallet-kit`, see [Advanced backend authentication](/sdks/react/advanced-backend-authentication) for how to wire this up on the frontend. For a working implementation of this flow, see the [oauth example](https://github.com/tkhq/sdk/tree/main/examples/oauth) in the SDK — it uses Google as the provider, but the client/backend split and nonce binding pattern are identical for any OIDC issuer.
+If you are using `@turnkey/react-wallet-kit`, see [Advanced backend authentication](/solutions/embedded-wallets/integration-guide/react/advanced-backend-authentication) for how to wire this up on the frontend. For a working implementation of this flow, see the [oauth example](https://github.com/tkhq/sdk/tree/main/examples/oauth) in the SDK — it uses Google as the provider, but the client/backend split and nonce binding pattern are identical for any OIDC issuer.
## Adding an OIDC provider to an existing user
diff --git a/authentication/email.mdx b/features/authentication/email.mdx
similarity index 85%
rename from authentication/email.mdx
rename to features/authentication/email.mdx
index e7789371..4b80ec29 100644
--- a/authentication/email.mdx
+++ b/features/authentication/email.mdx
@@ -60,7 +60,7 @@ The legacy iframe-based flow using `INIT_USER_EMAIL_RECOVERY` and `RECOVER_USER`
## Prerequisites
-Make sure you have set up your primary Turnkey organization with at least one API user that can programmatically initiate email auth and create suborganizations. Check out our [Quickstart guide](/getting-started/quickstart) if you need help getting started. To allow an API user to initiate email auth, you'll need the following policy in your main organization:
+Make sure you have set up your primary Turnkey organization with at least one API user that can programmatically initiate email auth and create suborganizations. Check out our [Quickstart guide](/get-started/quickstart) if you need help getting started. To allow an API user to initiate email auth, you'll need the following policy in your main organization:
```json
{
@@ -113,8 +113,6 @@ After receiving the verification token, users complete OTP authentication flow w
- `expirationSeconds`: optional validity window (defaults to 15 minutes)
- `invalidateExisting`: optional boolean to invalidate previous login sessions
-- • For `email_recovery` or `email_auth`: include `appName` in your request
- • For `init_otp` or `init_otp_auth`: update your API call to match the new input structure when upgrading to the latest server-SDK -
- Old: `ACTIVITY_TYPE_EMAIL_AUTH`, `ACTIVITY_TYPE_EMAIL_AUTH_V2`
- New: `ACTIVITY_TYPE_EMAIL_AUTH_V3` +```js +await client.emailAuth({ + parameters: { + email: "user@example.com", + targetPublicKey: "
- Old: `ACTIVITY_TYPE_INIT_OTP_AUTH`, `ACTIVITY_TYPE_INIT_OTP_AUTH_V2`
- New: `ACTIVITY_TYPE_INIT_OTP_AUTH_V3` +**`initOtp` and `initOtpAuth`** — both methods use the same parameter structure: - **INIT_OTP** (contact verification & signup)
- Old: `ACTIVITY_TYPE_INIT_OTP`, `ACTIVITY_TYPE_INIT_OTP_V2`
- New: `ACTIVITY_TYPE_INIT_OTP_V3` +```js +await client.initOtp({ + parameters: { + otpType: "OTP_TYPE_EMAIL", + contact: "user@example.com", + appName: "Your App Name", // this is now required + emailCustomization: { + // other optional customization + } + } +}); +``` - **VERIFY_OTP**
- Old: `ACTIVITY_TYPE_VERIFY_OTP`
- New: `ACTIVITY_TYPE_VERIFY_OTP_V2` + - **OTP_LOGIN**
- Old: `ACTIVITY_TYPE_OTP_LOGIN`
- New: `ACTIVITY_TYPE_OTP_LOGIN_V2` +
- Old: `ACTIVITY_TYPE_INIT_USER_EMAIL_RECOVERY`
- New: `ACTIVITY_TYPE_INIT_USER_EMAIL_RECOVERY_V2` -
+
diff --git a/authentication/passkeys/discoverable-vs-non-discoverable.mdx b/features/authentication/passkeys/discoverable-vs-non-discoverable.mdx
similarity index 100%
rename from authentication/passkeys/discoverable-vs-non-discoverable.mdx
rename to features/authentication/passkeys/discoverable-vs-non-discoverable.mdx
diff --git a/authentication/passkeys/integration.mdx b/features/authentication/passkeys/integration.mdx
similarity index 96%
rename from authentication/passkeys/integration.mdx
rename to features/authentication/passkeys/integration.mdx
index 8071486c..39978ad2 100644
--- a/authentication/passkeys/integration.mdx
+++ b/features/authentication/passkeys/integration.mdx
@@ -63,7 +63,7 @@ const completedActivity = await activityPoller({
* [`@turnkey/viem`](https://www.npmjs.com/package/@turnkey/viem) is a package wrapping all of the above so that you work directly with Viem without worrying about passkeys. See [this demo](https://github.com/tkhq/demo-viem-passkeys).
-Regardless of whether you use our helpers and abstractions, take a look at [our registration and authentication options guide](/authentication/passkeys/options). This will help you choose the right options for your passkey flow.
+Regardless of whether you use our helpers and abstractions, take a look at [our registration and authentication options guide](/features/authentication/passkeys/options). This will help you choose the right options for your passkey flow.
If you have questions, feedback, or find yourself in need of an abstraction or integration that doesn't exist yet, please get in touch with us! You can
@@ -75,4 +75,4 @@ We're here to make this as easy as possible for you and your team!
## Passkey wallets with sub-organizations
-If you're wondering how to create independent, non-custodial wallets for your end-users, head to [Sub-Organizations](/concepts/sub-organizations). In short: you'll be able to pass the registered passkeys as part of a "create sub-organization" activity, making your end-users the sole owners of any resource created within the sub-organization (including private keys). Your organization will only have read permissions.
\ No newline at end of file
+If you're wondering how to create independent, non-custodial wallets for your end-users, head to [Sub-Organizations](/features/sub-organizations). In short: you'll be able to pass the registered passkeys as part of a "create sub-organization" activity, making your end-users the sole owners of any resource created within the sub-organization (including private keys). Your organization will only have read permissions.
\ No newline at end of file
diff --git a/authentication/passkeys/introduction.mdx b/features/authentication/passkeys/introduction.mdx
similarity index 98%
rename from authentication/passkeys/introduction.mdx
rename to features/authentication/passkeys/introduction.mdx
index aafd8a4a..7697d31e 100644
--- a/authentication/passkeys/introduction.mdx
+++ b/features/authentication/passkeys/introduction.mdx
@@ -54,4 +54,4 @@ We believe **it's time to move away from passwords** so we've built Turnkey with
Authentication to Turnkey requires a passkey signature. No password needed!
-Next up, learn about how you can integrate passkeys into your app, [here](/authentication/passkeys/integration).
+Next up, learn about how you can integrate passkeys into your app, [here](/features/authentication/passkeys/integration).
diff --git a/authentication/passkeys/native.mdx b/features/authentication/passkeys/native.mdx
similarity index 100%
rename from authentication/passkeys/native.mdx
rename to features/authentication/passkeys/native.mdx
diff --git a/authentication/passkeys/options.mdx b/features/authentication/passkeys/options.mdx
similarity index 96%
rename from authentication/passkeys/options.mdx
rename to features/authentication/passkeys/options.mdx
index fc31db06..260f29dd 100644
--- a/authentication/passkeys/options.mdx
+++ b/features/authentication/passkeys/options.mdx
@@ -84,7 +84,7 @@ This option, if set, restricts the type of authenticators that can be registered
#### `requireResidentKey` and `residentKey`
-These options allow you to specify whether you want your users to create discoverable or non-discoverable credentials. See [Discoverable vs. non-discoverable](/authentication/passkeys/discoverable-vs-non-discoverable) for more information. Default values: `residentKey` is `discouraged` and `requireResidentKey` is `false`.
+These options allow you to specify whether you want your users to create discoverable or non-discoverable credentials. See [Discoverable vs. non-discoverable](/features/authentication/passkeys/discoverable-vs-non-discoverable) for more information. Default values: `residentKey` is `discouraged` and `requireResidentKey` is `false`.
Important note: the default for `requireResidentKey` (`discouraged`) results in different outcomes based on OS: Android devices create non-discoverable credentials whereas iOS devices create discoverable credentials. If you want to create discoverable credentials whenever possible, set `requireResidentKey` to `false` and `residentKey` to `preferred`, which work across Android and iOS devices.
@@ -116,7 +116,7 @@ Must match the `rp.id` option during passkey registration. Passkeys are domain b
### `allowCredentials`
-List of objects restricting which credentials can be used during authentication. This is crucial to specify if you're using [non-discoverable credentials](/authentication/passkeys/discoverable-vs-non-discoverable#non-discoverable-credentials) or if you want to tailor browser prompts to the right type of transport.
+List of objects restricting which credentials can be used during authentication. This is crucial to specify if you're using [non-discoverable credentials](/features/authentication/passkeys/discoverable-vs-non-discoverable#non-discoverable-credentials) or if you want to tailor browser prompts to the right type of transport.
Each object in this list has an ID (the credential ID) and a list of transports (e.g. "hybrid", "internal", "usb", etc). The `transports` list is **optional** but results in better, more targeted prompts. For example, here are screenshot of targeted prompts captured on Chrome, on a MacBook laptop:
diff --git a/authentication/proxying-signed-requests.mdx b/features/authentication/proxying-signed-requests.mdx
similarity index 100%
rename from authentication/proxying-signed-requests.mdx
rename to features/authentication/proxying-signed-requests.mdx
diff --git a/authentication/sessions.mdx b/features/authentication/sessions.mdx
similarity index 100%
rename from authentication/sessions.mdx
rename to features/authentication/sessions.mdx
diff --git a/authentication/sms.mdx b/features/authentication/sms.mdx
similarity index 91%
rename from authentication/sms.mdx
rename to features/authentication/sms.mdx
index 09fdfe55..618667e5 100644
--- a/authentication/sms.mdx
+++ b/features/authentication/sms.mdx
@@ -20,7 +20,7 @@ Select your country below to view pricing.
## Prerequisites
-Make sure you have set up your primary Turnkey organization with at least one API user that can programmatically initiate OTP and create sub-organizations. Check out our [Quickstart guide](/getting-started/quickstart) if you need help getting started. To allow an API user to initiate email auth, you'll need the following policy in your main organization:
+Make sure you have set up your primary Turnkey organization with at least one API user that can programmatically initiate OTP and create sub-organizations. Check out our [Quickstart guide](/get-started/quickstart) if you need help getting started. To allow an API user to initiate email auth, you'll need the following policy in your main organization:
```json
{
@@ -38,7 +38,6 @@ SMS authentication uses three activities:
2. `VERIFY_OTP_V2` — securely verifies the code and returns a signed verificationToken JWT
3. `OTP_LOGIN_V2` — validates the verificationToken and returns a session (signed with the verification token key)
-
+
diff --git a/concepts/policies/delegated-access-backend.mdx b/features/policies/delegated-access/backend.mdx
similarity index 97%
rename from concepts/policies/delegated-access-backend.mdx
rename to features/policies/delegated-access/backend.mdx
index 8ca25486..719c9be4 100644
--- a/concepts/policies/delegated-access-backend.mdx
+++ b/features/policies/delegated-access/backend.mdx
@@ -74,7 +74,7 @@ A simple example demonstrating the server-side delegated access setup can be fou
}
```
-### Step 2: limit the permissions of the Delegated Account user via policies
+### Step 2: limit the permissions of the delegated account user via policies
- Create a custom policy granting the Delegated Account specific permissions. You might grant that user permissions to:
- Sign any transaction
@@ -100,7 +100,7 @@ Here’s one example, granting the Delegated Account only the permission to sign
}
```
-### Step 3: remove the Delegated Account from the root quorum using the Delegated Account's credentials:
+### Step 3: remove the delegated account from the root quorum using the delegated account's credentials:
```json
// Update the root quorum of the sub organization to ONLY include the end user, removing the delegated access user
diff --git a/concepts/policies/delegated-access-frontend.mdx b/features/policies/delegated-access/frontend.mdx
similarity index 100%
rename from concepts/policies/delegated-access-frontend.mdx
rename to features/policies/delegated-access/frontend.mdx
diff --git a/concepts/policies/delegated-access-overview.mdx b/features/policies/delegated-access/overview.mdx
similarity index 98%
rename from concepts/policies/delegated-access-overview.mdx
rename to features/policies/delegated-access/overview.mdx
index 0c82b75e..8d57ccf0 100644
--- a/concepts/policies/delegated-access-overview.mdx
+++ b/features/policies/delegated-access/overview.mdx
@@ -29,7 +29,7 @@ This avoids temporarily granting the Delegated User root access — see [Caution
**Limitations:**
- You can’t assume the delegated user or its policies already exist. Before referencing it, you’ll need to call `fetchOrCreateP256ApiKeyUser` and `fetchOrCreatePolicies` to ensure the user and permissions are properly set up.
-For a detailed step-by-step guide see [Client-side Delegated Access setup](/concepts/policies/delegated-access-frontend).
+For a detailed step-by-step guide see [Client-side Delegated Access setup](/features/policies/delegated-access/frontend).
### 2. Backend
@@ -56,9 +56,9 @@ If you adopt this approach, implement strict validation to confirm that:
For most end-user applications, it’s recommended to perform delegated access setup client-side, where all actions are explicitly initiated and approved by the user.
-For a detailed step-by-step guide see [Server-side Delegated Access setup](/concepts/policies/delegated-access-backend).
+For a detailed step-by-step guide see [Server-side Delegated Access setup](/features/policies/delegated-access/backend).
-## Frequently Asked Questions
+## Frequently asked questions
### Policy design and creation
diff --git a/concepts/policies/examples/access-control.mdx b/features/policies/examples/access-control.mdx
similarity index 95%
rename from concepts/policies/examples/access-control.mdx
rename to features/policies/examples/access-control.mdx
index a1585e28..db3c4d6f 100644
--- a/concepts/policies/examples/access-control.mdx
+++ b/features/policies/examples/access-control.mdx
@@ -59,7 +59,7 @@ sidebarTitle: "Access control"
}
```
-#### Allow a specific user to perform auth type activities (full list [here](/concepts/policies/language#activity-breakdown))
+#### Allow a specific user to perform auth type activities (full list [here](/features/policies/language#activity-breakdown))
Note: The `activity.resource` portion determines which activities can be performed. The `activity.action` determines what types of actions can be taken upon those resources.
@@ -83,7 +83,7 @@ Note: The `activity.resource` portion determines which activities can be perform
}
```
-#### Allow a specific user to perform a specific activity type (full list [here](/concepts/policies/language#activity-breakdown))
+#### Allow a specific user to perform a specific activity type (full list [here](/features/policies/language#activity-breakdown))
Note: Activities may be upgraded over time, and thus new versions may be introduced.
These policies will NOT be valid if an activity type is upgraded and requests are made on the new activity type.
@@ -99,7 +99,7 @@ and a request is made with the newer `V3` version, this policy with not allow th
}
```
-#### Allow a specific credential type to perform a specific action (full list of credential types [here](/authentication/credentials#credential-types))
+#### Allow a specific credential type to perform a specific action (full list of credential types [here](/features/users/credentials#credential-types))
This policy can be used to say, only passkeys are allowed to sign transactions and not authentication through SMS (or any other authentication method).
diff --git a/concepts/policies/examples/bitcoin.mdx b/features/policies/examples/bitcoin.mdx
similarity index 91%
rename from concepts/policies/examples/bitcoin.mdx
rename to features/policies/examples/bitcoin.mdx
index c7d7ff45..8e3a342d 100644
--- a/concepts/policies/examples/bitcoin.mdx
+++ b/features/policies/examples/bitcoin.mdx
@@ -4,7 +4,7 @@ description: "This page provides examples of policies governing Bitcoin signing.
sidebarTitle: "Bitcoin"
---
-Note: see the [language section](/concepts/policies/language#bitcoin) for more details. For context on Bitcoin transaction reinsertion, see the [Bitcoin network support](/networks/bitcoin) page
+Note: see the [language section](/features/policies/language#bitcoin) for more details. For context on Bitcoin transaction reinsertion, see the [Bitcoin network support](/features/networks/bitcoin) page
#### Allow signing Bitcoin transactions ONLY if all outputs are being sent to a certain address
diff --git a/company-wallets/co-signing-transactions.mdx b/features/policies/examples/co-signing-transactions.mdx
similarity index 100%
rename from company-wallets/co-signing-transactions.mdx
rename to features/policies/examples/co-signing-transactions.mdx
diff --git a/concepts/policies/examples/ethereum.mdx b/features/policies/examples/ethereum.mdx
similarity index 98%
rename from concepts/policies/examples/ethereum.mdx
rename to features/policies/examples/ethereum.mdx
index b6b4699d..191fa723 100644
--- a/concepts/policies/examples/ethereum.mdx
+++ b/features/policies/examples/ethereum.mdx
@@ -4,7 +4,7 @@ description: "This page provides examples of policies governing Ethereum (EVM) s
sidebarTitle: "Ethereum (EVM)"
---
-Note: see the [language section](/concepts/policies/language#ethereum) for more details.
+Note: see the [language section](/features/policies/language#ethereum) for more details.
#### Allow ABI-specific contract call parameters
diff --git a/concepts/policies/examples/signing-control.mdx b/features/policies/examples/signing-control.mdx
similarity index 100%
rename from concepts/policies/examples/signing-control.mdx
rename to features/policies/examples/signing-control.mdx
diff --git a/concepts/policies/examples/solana.mdx b/features/policies/examples/solana.mdx
similarity index 98%
rename from concepts/policies/examples/solana.mdx
rename to features/policies/examples/solana.mdx
index 9a919422..a6086eec 100644
--- a/concepts/policies/examples/solana.mdx
+++ b/features/policies/examples/solana.mdx
@@ -4,11 +4,11 @@ description: "This page provides examples of policies governing Solana signing."
sidebarTitle: "Solana"
---
-Note: see the [language section](/concepts/policies/language#solana) for various approaches on writing Solana policies.
+Note: see the [language section](/features/policies/language#solana) for various approaches on writing Solana policies.
+
+
+## Core concepts
+
+- **Organization** — Top-level entity representing your application. Contains users, wallets, and policies.
+- **Sub-organization** — Fully isolated organization nested under the parent, typically representing an end user or business customer. Parent orgs have read-only access and cannot modify sub-org contents.
+- **User** — A resource within an org or sub-org that submits activities via a valid credential. Users can have tags, which policies reference for role-based controls.
+- **Root user / root quorum** — Root users can bypass the policy engine. A root quorum sets the approval threshold required to exercise root permissions.
+- **Authenticator** — A credential used to stamp API requests: passkeys, API keys, email OTP, or OAuth.
+- **Activity** — Any action submitted to Turnkey (sign transaction, create user, update policy). All activities are evaluated by the policy engine.
+- **Policy** — A logical rule that evaluates to ALLOW, DENY, or REQUIRES_CONSENSUS. Controls who can sign what, under what conditions.
+- **Wallet** — An HD wallet (seed phrase) that generates multiple accounts across chains. Lives inside the enclave; only addresses and signatures are returned.
+
+## Where to start
+
+- **Explore by use case** — [Embedded Wallets](/solutions/embedded-wallets/overview), [Company Wallets](/solutions/company-wallets/overview), [Key Management](/solutions/key-management/overview)
+- **Account setup** — [create your org and API key](/get-started/quickstart)
+- **SDKs** — [client libraries](/sdks/introduction) for React, React Native, Swift, Kotlin, Flutter, and more
+- **Security** — [how the enclave model works](/security/our-approach) and what Turnkey's security guarantees are
+- **AI-ready docs** — [use Turnkey docs](/get-started/using-llms) with Cursor, ChatGPT, or your own LLM tooling
diff --git a/ai/skills.mdx b/get-started/ai-skills.mdx
similarity index 80%
rename from ai/skills.mdx
rename to get-started/ai-skills.mdx
index 8d35dafc..1cd9e3fc 100644
--- a/ai/skills.mdx
+++ b/get-started/ai-skills.mdx
@@ -3,9 +3,12 @@ title: "Agent Skills"
description: "Opinionated instructions that tell AI agents how to interact with Turnkey through conversation, not code."
---
+import { FeatureCard } from '/snippets/feature-card.mdx'
+import { SolutionCard } from '/snippets/solution-card.mdx'
+
Each agent skill is a `SKILL.md` file with opinionated, step-by-step instructions for a specific Turnkey operation. Instead of an agent reasoning about API docs, parameter formatting, and chain-specific details on its own, skills give it exactly what it needs to execute correctly. Skills work with Claude Code, OpenAI, and other third-party agent frameworks.
-Skills are for interacting with Turnkey directly through an AI assistant, not for building the application layer on top of Turnkey. If you're using a coding agent to develop a Turnkey integration, connect it to the [Docs MCP server](/developer-reference/using-llms) instead.
+Skills are for interacting with Turnkey directly through an AI assistant, not for building the application layer on top of Turnkey. If you're using a coding agent to develop a Turnkey integration, connect it to the [Docs MCP server](/get-started/using-llms) instead.
Skills are open source at [**tkhq/turnkey-agent-skills**](https://github.com/tkhq/turnkey-agent-skills) on GitHub.
@@ -36,7 +39,7 @@ All skills require an API key pair and organization ID from the [Turnkey Dashboa
| Setup | Credential type | When to use |
| :--- | :--- | :--- |
| **Interactive assistant** (human approves each action) | Root API key (with extreme caution) or a scoped, non-root API key | Organization administration, testing, and exploration. Human should review every action before it executes. |
-| **Autonomous agent** (acts without human review) | Scoped, non-root API key | Production automation. **Never use root credentials for autonomous agents.** Root keys bypass all policies. Create a non-root user with scoped policies instead. See [Agentic Wallets](/company-wallets/use-cases/agentic-wallets) and the `provisioning-agent` skill. |
+| **Autonomous agent** (acts without human review) | Scoped, non-root API key | Production automation. **Never use root credentials for autonomous agents.** Root keys bypass all policies. Create a non-root user with scoped policies instead. See [Agentic Wallets](/solutions/company-wallets/agentic-wallets) and the `provisioning-agent` skill. |
## Available skills
@@ -68,3 +71,12 @@ Clone the repo and point your AI assistant at the skill files:
git clone https://github.com/tkhq/turnkey-agent-skills.git
cd turnkey-agent-skills
```
+
+## Next steps
+
+
+
diff --git a/production-checklist/backup-recovery.mdx b/get-started/backup-recovery.mdx
similarity index 61%
rename from production-checklist/backup-recovery.mdx
rename to get-started/backup-recovery.mdx
index 5db22d21..f17cd526 100644
--- a/production-checklist/backup-recovery.mdx
+++ b/get-started/backup-recovery.mdx
@@ -1,6 +1,6 @@
---
title: "Backup and recovery"
-description: "In line with responsible practices, backup and recovery of Turnkey accounts and/or wallets is an important consideration when designing any production system. The specific mechanisms (such as [wallet exports](/wallets/export-wallets)) are outlined in greater detail elsewhere - the purpose of this document is to inform and guide how to use the mechanisms available."
+description: "In line with responsible practices, backup and recovery of Turnkey accounts and/or wallets is an important consideration when designing any production system. The specific mechanisms (such as [wallet exports](/features/wallets/export-wallets)) are outlined in greater detail elsewhere - the purpose of this document is to inform and guide how to use the mechanisms available."
---
It is Turnkey's approach that the safest place for key material is within the hardened [secure enclaves](security/secure-enclaves), and within these enclaves alone. Our model guides using authenticators (or combinations thereof) of increasing sophistication, relating to the importance or consequences of a given action. For example, a full recovery of an organization may require multiple break-glass hardware authenticators, where a routine low-stakes action might only rely on an API key.
@@ -9,11 +9,11 @@ The below options all involve some combination of authentication methods and pol
## Root user recovery
-Touched on in the [production checklist](/production-checklist/production-checklist#security), the **native** method of organization recovery in Turnkey is to configure multiple root users (recommended at least 3), who each have hardware authenticators such as biometric auth (TouchID on a MacBook) or a YubiKey physical passkey. With at least 3 root users, it is possible to set up a 2 of 3 [root quorum](/concepts/users/root-quorum) which can bypass the policy engine and assert maximum authority in the case of disaster recovery - even when one root user may have lost their authenticator.
+Touched on in the [production checklist](/get-started/production-checklist#security), the **native** method of organization recovery in Turnkey is to configure multiple root users (recommended at least 3), who each have hardware authenticators such as biometric auth (TouchID on a MacBook) or a YubiKey physical passkey. With at least 3 root users, it is possible to set up a 2 of 3 [root quorum](/features/users/root-quorum) which can bypass the policy engine and assert maximum authority in the case of disaster recovery - even when one root user may have lost their authenticator.
### Sub-organizations
-In a typical non-custodial/embedded wallet configuration, the same root user recovery approach can be effectively used. One could decide on a single ultimate recovery method, such as a passkey or [email-based recovery](/authentication/email), or a combination of multiple methods mirroring the previously outlined _n_ of _m_.
+In a typical non-custodial/embedded wallet configuration, the same root user recovery approach can be effectively used. One could decide on a single ultimate recovery method, such as a passkey or [email-based recovery](/features/authentication/email), or a combination of multiple methods mirroring the previously outlined _n_ of _m_.
### Account based authenticators
@@ -23,13 +23,13 @@ An additional consideration for account-based authenticators (such as email or s
Using additional authenticators for recovery is preferred since it ensures wallets never leave the enclave. However, it is also possible for the user to backup their key material outside of Turnkey.
-Wallets, wallet accounts, and raw private keys can all be exported securely using an [embedded iframe](/embedded-wallets/code-examples/export#embedded-iframe) which ensures the key material remains encrypted while being sent from Turnkey’s enclave to the user’s device.
+Wallets, wallet accounts, and raw private keys can all be exported securely using an [embedded iframe](/solutions/embedded-wallets/integration-guide/react/using-embedded-wallets#embedded-iframe) which ensures the key material remains encrypted while being sent from Turnkey’s enclave to the user’s device.
With this process, users have two main options:
-1. Expose the seed phrase to the user in plaintext clientside so they can record it manually. See [wallet exports](/wallets/export-wallets) for more detail.
+1. Expose the seed phrase to the user in plaintext clientside so they can record it manually. See [wallet exports](/features/wallets/export-wallets) for more detail.
2. Encrypt the seed phrase to a user defined passphrase (using [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2)). Contact Turnkey support if you’re interested in this implementation.
-For non-embedded wallets, [scripted exports](/embedded-wallets/code-examples/export#nodejs) are also possible.
+For non-embedded wallets, [scripted exports](/solutions/embedded-wallets/integration-guide/react/using-embedded-wallets#nodejs) are also possible.
diff --git a/getting-started/examples.mdx b/get-started/examples.mdx
similarity index 50%
rename from getting-started/examples.mdx
rename to get-started/examples.mdx
index c9e0f331..76c5d074 100644
--- a/getting-started/examples.mdx
+++ b/get-started/examples.mdx
@@ -1,137 +1,145 @@
---
-title: "Examples"
-description: "Turnkey infrastructure is flexible by default. We intentionally prioritize low-level primitives in our product to avoid creating blockers for developers building new kinds of applications on Turnkey."
+title: "Code examples"
+description:
+ "Turnkey infrastructure is flexible by default. We intentionally prioritize low-level primitives
+ in our product to avoid creating blockers for developers building new kinds of applications on
+ Turnkey."
---
-That said, we have built out several example services and applications to help illustrate the types of functionality that Turnkey can enable.
+That said, we have built out several example services and applications to help illustrate the types
+of functionality that Turnkey can enable.
## Demos
Full end-to-end applications to see everything working together.
-| Example | Description |
-| ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| [`react-wallet-kit`](https://github.com/tkhq/sdk/tree/main/examples/react-wallet-kit) | Comprehensive demo of embedded wallet kit with auth, wallet management, signing, import/export |
-| [`demo-embedded-wallet`](https://github.com/tkhq/demo-embedded-wallet) | A minimal consumer wallet app powered by Turnkey and passkeys, with transaction sending |
-| [`demo-consumer-wallet`](https://github.com/tkhq/demo-consumer-wallet) | A minimal consumer wallet app powered by Turnkey and WalletConnect |
-| [`with-react-native-wallet-kit`](https://github.com/tkhq/sdk/tree/main/examples/with-react-native-wallet-kit) | A React Native app demonstrating how to use `@turnkey/react-native-wallet-kit` to authenticate users, create wallets, export wallets, sign messages, and more |
-| [`flutter-demo-app`](https://github.com/tkhq/dart-sdk/tree/main/examples/flutter-demo-app) | A Flutter app that demonstrates how to use the Turnkey's Flutter packages to authenticate users, create wallets, export wallets, sign messages, and more |
-| [`swift-sdk/Examples`](https://github.com/tkhq/swift-sdk/tree/main/Examples) | Native iOS wallet app with OTP, OAuth, and passkey auth, wallet creation, message signing, and transaction sending |
+| Example | Description |
+| ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [`react-wallet-kit`](https://github.com/tkhq/sdk/tree/main/examples/react-wallet-kit) | Comprehensive demo of embedded wallet kit with auth, wallet management, signing, import/export |
+| [`demo-embedded-wallet`](https://github.com/tkhq/demo-embedded-wallet) | A minimal consumer wallet app powered by Turnkey and passkeys, with transaction sending |
+| [`demo-consumer-wallet`](https://github.com/tkhq/demo-consumer-wallet) | A minimal consumer wallet app powered by Turnkey and WalletConnect |
+| [`with-react-native-wallet-kit`](https://github.com/tkhq/sdk/tree/main/examples/with-react-native-wallet-kit) | A React Native app demonstrating how to use `@turnkey/react-native-wallet-kit` to authenticate users, create wallets, export wallets, sign messages, and more |
+| [`flutter-demo-app`](https://github.com/tkhq/dart-sdk/tree/main/examples/flutter-demo-app) | A Flutter app that demonstrates how to use the Turnkey's Flutter packages to authenticate users, create wallets, export wallets, sign messages, and more |
+| [`swift-sdk/Examples`](https://github.com/tkhq/swift-sdk/tree/main/Examples) | Native iOS wallet app with OTP, OAuth, and passkey auth, wallet creation, message signing, and transaction sending |
## Authentication
-| Example | Description |
-| ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ |
-| [`oauth`](https://github.com/tkhq/sdk/tree/main/examples/oauth) | OAuth login (Google) integration with Turnkey via backend server actions |
-| [`otp-auth`](https://github.com/tkhq/sdk/tree/main/examples/otp-auth) | Email OTP authentication with Auth Proxy and a custom backend |
-| [`magic-link-auth`](https://github.com/tkhq/sdk/tree/main/examples/magic-link-auth) | Magic link login/signup flow using Turnkey's email OTP system |
-| [`wallet-auth`](https://github.com/tkhq/sdk/tree/main/examples/wallet-auth) | External wallet authentication (MetaMask, Phantom, etc.) with Auth Proxy and custom backend |
-| [`with-wallet-stamper`](https://github.com/tkhq/sdk/tree/main/examples/with-wallet-stamper) | Demonstrates `@turnkey/wallet-stamper` for signing Turnkey requests with an external wallet |
+| Example | Description |
+| ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
+| [`oauth`](https://github.com/tkhq/sdk/tree/main/examples/oauth) | OAuth login (Google) integration with Turnkey via backend server actions |
+| [`otp-auth`](https://github.com/tkhq/sdk/tree/main/examples/otp-auth) | Email OTP authentication with Auth Proxy and a custom backend |
+| [`magic-link-auth`](https://github.com/tkhq/sdk/tree/main/examples/magic-link-auth) | Magic link login/signup flow using Turnkey's email OTP system |
+| [`wallet-auth`](https://github.com/tkhq/sdk/tree/main/examples/wallet-auth) | External wallet authentication (MetaMask, Phantom, etc.) with Auth Proxy and custom backend |
+| [`with-wallet-stamper`](https://github.com/tkhq/sdk/tree/main/examples/with-wallet-stamper) | Demonstrates `@turnkey/wallet-stamper` for signing Turnkey requests with an external wallet |
## Key & Wallet Management
-| Example | Description |
-| -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
-| [`import-export-with-rwk`](https://github.com/tkhq/sdk/tree/main/examples/import-export-with-rwk) | Wallet import and export using React Wallet Kit and Auth Proxy |
-| [`import-export-with-iframe-stamper`](https://github.com/tkhq/sdk/tree/main/examples/import-export-with-iframe-stamper) | Wallet import/export via `@turnkey/iframe-stamper` |
-| [`wallet-export-sign`](https://github.com/tkhq/sdk/tree/main/examples/wallet-export-sign) | Wallet export and signing operations via Turnkey iframe |
-| [`export-in-node`](https://github.com/tkhq/sdk/tree/main/examples/export-in-node) | Wallet export performed on the backend |
-| [`import-in-node`](https://github.com/tkhq/sdk/tree/main/examples/import-in-node) | Wallet import performed on the backend |
-| [`disaster-recovery`](https://github.com/tkhq/sdk/tree/main/examples/disaster-recovery) | Wallet disaster recovery with direct import or encryption key escrow |
-| [`encryption-key-escrow`](https://github.com/tkhq/sdk/tree/main/examples/encryption-key-escrow) | Use Turnkey to store encryption keys for external recovery bundles |
+| Example | Description |
+| ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
+| [`import-export-with-rwk`](https://github.com/tkhq/sdk/tree/main/examples/import-export-with-rwk) | Wallet import and export using React Wallet Kit and Auth Proxy |
+| [`import-export-with-iframe-stamper`](https://github.com/tkhq/sdk/tree/main/examples/import-export-with-iframe-stamper) | Wallet import/export via `@turnkey/iframe-stamper` |
+| [`wallet-export-sign`](https://github.com/tkhq/sdk/tree/main/examples/wallet-export-sign) | Wallet export and signing operations via Turnkey iframe |
+| [`export-in-node`](https://github.com/tkhq/sdk/tree/main/examples/export-in-node) | Wallet export performed on the backend |
+| [`import-in-node`](https://github.com/tkhq/sdk/tree/main/examples/import-in-node) | Wallet import performed on the backend |
+| [`disaster-recovery`](https://github.com/tkhq/sdk/tree/main/examples/disaster-recovery) | Wallet disaster recovery with direct import or encryption key escrow |
+| [`encryption-key-escrow`](https://github.com/tkhq/sdk/tree/main/examples/encryption-key-escrow) | Use Turnkey to store encryption keys for external recovery bundles |
## Signing
Signers and chain-specific transaction examples.
-| Example | Description |
-| --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Example | Description |
+| -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [`with-ethers`](https://github.com/tkhq/sdk/tree/main/examples/with-ethers/) | Sign messages, send EIP-1559 and legacy transactions, interact with contracts (WETH), and sign EIP-712 typed data (ERC-2612 permit, ERC-3009, Hyperliquid) using `@turnkey/ethers` |
-| [`with-viem`](https://github.com/tkhq/sdk/tree/main/examples/with-viem/) | Sign messages, send transactions, sign EIP-712 typed data, and sign EIP-4844 and EIP-7702 transactions using `@turnkey/viem` |
-| [`with-eip-1193-provider`](https://github.com/tkhq/sdk/tree/main/examples/with-eip-1193-provider/) | Turnkey-compatible Ethereum provider adhering to the EIP-1193 standard |
-| [`with-nonce-manager`](https://github.com/tkhq/sdk/tree/main/examples/with-nonce-manager/) | Sign and broadcast multiple Ethereum transactions sequentially or optimistically |
-| [`with-cosmjs`](https://github.com/tkhq/sdk/tree/main/examples/with-cosmjs/) | Sign and broadcast a Cosmos transaction on Celestia testnet using `@turnkey/cosmjs` |
-| [`with-solana`](https://github.com/tkhq/sdk/tree/main/examples/with-solana/) | Sign and broadcast Solana transactions using `@turnkey/solana`, including SPL token creation \+ transfer |
-| [`with-bitcoin`](https://github.com/tkhq/sdk/tree/main/examples/with-bitcoin) | Construct, sign, and broadcast a Bitcoin transaction using bitcoinjs-lib |
-| [`with-doge`](https://github.com/tkhq/sdk/tree/main/examples/with-doge) | Dogecoin testnet transaction signing using bitcoinjs-lib |
-| [`with-aptos`](https://github.com/tkhq/sdk/tree/main/examples/with-aptos) | Aptos transaction construction and mainnet fund transfer |
-| [`with-ton`](https://github.com/tkhq/sdk/tree/main/examples/with-ton) | TON transaction construction and mainnet fund transfer |
-| [`with-tron`](https://github.com/tkhq/sdk/tree/main/examples/with-tron) | Tron wallet creation, signing, testnet funding, and policy guards |
-| [`with-stacks`](https://github.com/tkhq/sdk/tree/main/examples/with-stacks) | Stacks transaction signing with secp256k1 |
-| [`with-movement`](https://github.com/tkhq/sdk/tree/main/examples/with-movement) | Movement transaction construction and mainnet fund transfer |
-| [`with-arc`](https://github.com/tkhq/sdk/tree/main/examples/with-arc) | Arc testnet transaction construction and broadcast |
-| [`with-tempo`](https://github.com/tkhq/sdk/tree/main/examples/with-tempo) | Tempo testnet transaction construction and broadcast |
-| [`with-sui`](https://github.com/tkhq/sdk/tree/main/examples/with-sui) | Construct, sign, and broadcast a Sui transaction using Turnkey |
-| [`with-iota`](https://github.com/tkhq/sdk/tree/main/examples/with-iota) | Build, sign, and broadcast IOTA transactions using Turnkey |
+| [`with-viem`](https://github.com/tkhq/sdk/tree/main/examples/with-viem/) | Sign messages, send transactions, sign EIP-712 typed data, and sign EIP-4844 and EIP-7702 transactions using `@turnkey/viem` |
+| [`with-eip-1193-provider`](https://github.com/tkhq/sdk/tree/main/examples/with-eip-1193-provider/) | Turnkey-compatible Ethereum provider adhering to the EIP-1193 standard |
+| [`with-nonce-manager`](https://github.com/tkhq/sdk/tree/main/examples/with-nonce-manager/) | Sign and broadcast multiple Ethereum transactions sequentially or optimistically |
+| [`with-cosmjs`](https://github.com/tkhq/sdk/tree/main/examples/with-cosmjs/) | Sign and broadcast a Cosmos transaction on Celestia testnet using `@turnkey/cosmjs` |
+| [`with-solana`](https://github.com/tkhq/sdk/tree/main/examples/with-solana/) | Sign and broadcast Solana transactions using `@turnkey/solana`, including SPL token creation \+ transfer |
+| [`with-bitcoin`](https://github.com/tkhq/sdk/tree/main/examples/with-bitcoin) | Construct, sign, and broadcast a Bitcoin transaction using bitcoinjs-lib |
+| [`with-doge`](https://github.com/tkhq/sdk/tree/main/examples/with-doge) | Dogecoin testnet transaction signing using bitcoinjs-lib |
+| [`with-aptos`](https://github.com/tkhq/sdk/tree/main/examples/with-aptos) | Aptos transaction construction and mainnet fund transfer |
+| [`with-ton`](https://github.com/tkhq/sdk/tree/main/examples/with-ton) | TON transaction construction and mainnet fund transfer |
+| [`with-tron`](https://github.com/tkhq/sdk/tree/main/examples/with-tron) | Tron wallet creation, signing, testnet funding, and policy guards |
+| [`with-stacks`](https://github.com/tkhq/sdk/tree/main/examples/with-stacks) | Stacks transaction signing with secp256k1 |
+| [`with-movement`](https://github.com/tkhq/sdk/tree/main/examples/with-movement) | Movement transaction construction and mainnet fund transfer |
+| [`with-arc`](https://github.com/tkhq/sdk/tree/main/examples/with-arc) | Arc testnet transaction construction and broadcast |
+| [`with-tempo`](https://github.com/tkhq/sdk/tree/main/examples/with-tempo) | Tempo testnet transaction construction and broadcast |
+| [`with-sui`](https://github.com/tkhq/sdk/tree/main/examples/with-sui) | Construct, sign, and broadcast a Sui transaction using Turnkey |
+| [`with-iota`](https://github.com/tkhq/sdk/tree/main/examples/with-iota) | Build, sign, and broadcast IOTA transactions using Turnkey |
## Turnkey Transaction Management
-| Example | Description |
-| ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
-| [`tk-gas-station`](https://github.com/tkhq/sdk/tree/main/examples/tk-gas-station) | Gasless transactions using Gas Station SDK with EIP-7702 authorization |
-| [`with-paymaster`](https://github.com/tkhq/sdk/tree/main/examples/with-paymaster) | ERC-20 token transfer on EVM with Turnkey paymaster gas sponsorship |
-| [`with-solana-paymaster`](https://github.com/tkhq/sdk/tree/main/examples/with-solana-paymaster) | SPL token transfer on Solana with Turnkey fee sponsorship |
-| [`with-balances`](https://github.com/tkhq/sdk/tree/main/examples/with-balances) | Fetch token balances and list supported assets using Turnkey APIs |
-| [`solana-sweeper`](https://github.com/tkhq/sdk/tree/main/examples/solana-sweeper) | Solana token sweeper utility |
-| [`solana-usdc-swap`](https://github.com/tkhq/sdk/tree/main/examples/solana-usdc-swap) | SOL to USDC swap on Solana mainnet via Jupiter |
-| [`sweeper`](https://github.com/tkhq/sdk/tree/main/examples/sweeper/) | Sweep funds from one address to a different address |
-| [`rebalancer`](https://github.com/tkhq/sdk/tree/main/examples/rebalancer/) | Manage and rebalance funds across multiple wallets and key types |
+| Example | Description |
+| ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
+| [`tk-gas-station`](https://github.com/tkhq/sdk/tree/main/examples/tk-gas-station) | Gasless transactions using Gas Station SDK with EIP-7702 authorization |
+| [`with-paymaster`](https://github.com/tkhq/sdk/tree/main/examples/with-paymaster) | ERC-20 token transfer on EVM with Turnkey paymaster gas sponsorship |
+| [`with-solana-paymaster`](https://github.com/tkhq/sdk/tree/main/examples/with-solana-paymaster) | SPL token transfer on Solana with Turnkey fee sponsorship |
+| [`with-balances`](https://github.com/tkhq/sdk/tree/main/examples/with-balances) | Fetch token balances and list supported assets using Turnkey APIs |
+| [`solana-sweeper`](https://github.com/tkhq/sdk/tree/main/examples/solana-sweeper) | Solana token sweeper utility |
+| [`solana-usdc-swap`](https://github.com/tkhq/sdk/tree/main/examples/solana-usdc-swap) | SOL to USDC swap on Solana mainnet via Jupiter |
+| [`sweeper`](https://github.com/tkhq/sdk/tree/main/examples/sweeper/) | Sweep funds from one address to a different address |
+| [`rebalancer`](https://github.com/tkhq/sdk/tree/main/examples/rebalancer/) | Manage and rebalance funds across multiple wallets and key types |
## Account Abstraction
-| Example | Description |
-| -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
+| Example | Description |
+| ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| [`with-zerodev-aa`](https://github.com/tkhq/sdk/tree/main/examples/with-zerodev-aa) | Transaction construction and broadcast with Turnkey, Viem, and ZeroDev account abstraction |
| [`with-biconomy-aa`](https://github.com/tkhq/sdk/tree/main/examples/with-biconomy-aa) | Transaction construction and broadcast with Turnkey, Viem, and Biconomy account abstraction |
## DeFi & Protocol Integrations
-| Example | Description |
-| ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------- |
-| [`with-uniswap`](https://github.com/tkhq/sdk/tree/main/examples/with-uniswap/) | Sign and broadcast a Uniswap v3 trade using the Ethers signer |
-| [`eth-usdc-swap`](https://github.com/tkhq/sdk/tree/main/examples/eth-usdc-swap) | ETH to USDC swap on Base mainnet via Uniswap Universal Router |
-| [`with-0x`](https://github.com/tkhq/sdk/tree/main/examples/with-0x) | EVM swapping ETH for USDC using 0x Swap API |
-| [`with-lifi`](https://github.com/tkhq/sdk/tree/main/examples/with-lifi) | EVM and SVM bridging between ETH and SOL using Li.Fi |
-| [`with-aave`](https://github.com/tkhq/sdk/tree/main/examples/with-aave) | Aave v3 USDC deposit/withdraw with Turnkey policy engine controls |
-| [`with-morpho`](https://github.com/tkhq/sdk/tree/main/examples/with-morpho) | Morpho Vaults USDC deposit/withdraw on Base Mainnet |
-| [`with-yield-xyz`](https://github.com/tkhq/sdk/tree/main/examples/with-yield-xyz) | Yield.xyz vaults deposit/withdraw across 75+ networks |
-| [`with-porto`](https://github.com/tkhq/sdk/tree/main/examples/with-porto) | Porto wallet upgrade and operations using API keys |
-| [`with-x402`](https://github.com/tkhq/sdk/tree/main/examples/with-x402) | Coinbase x402 payment protocol with embedded wallets |
-| [`with-jupiter`](https://github.com/tkhq/sdk/tree/main/examples/with-jupiter) | Solana token swaps using Jupiter Ultra Swap API |
-| [`with-breeze`](https://github.com/tkhq/sdk/tree/main/examples/with-breeze) | Solana USDC staking and yield management via Breeze API |
-| [`trading-runner`](https://github.com/tkhq/sdk/tree/main/examples/trading-runner/) | Multi-user Uniswap v3 trading demo with private key tags, user tags, and policies |
-| [`with-gnosis`](https://github.com/tkhq/sdk/tree/main/examples/with-gnosis/) | Create new Ethereum addresses, configure a 3/3 Gnosis safe, and create \+ execute a transaction from it |
+| Example | Description |
+| ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
+| [`with-uniswap`](https://github.com/tkhq/sdk/tree/main/examples/with-uniswap/) | Sign and broadcast a Uniswap v3 trade using the Ethers signer |
+| [`eth-usdc-swap`](https://github.com/tkhq/sdk/tree/main/examples/eth-usdc-swap) | ETH to USDC swap on Base mainnet via Uniswap Universal Router |
+| [`with-0x`](https://github.com/tkhq/sdk/tree/main/examples/with-0x) | EVM swapping ETH for USDC using 0x Swap API |
+| [`with-lifi`](https://github.com/tkhq/sdk/tree/main/examples/with-lifi) | EVM and SVM bridging between ETH and SOL using Li.Fi |
+| [`with-aave`](https://github.com/tkhq/sdk/tree/main/examples/with-aave) | Aave v3 USDC deposit/withdraw with Turnkey policy engine controls |
+| [`with-morpho`](https://github.com/tkhq/sdk/tree/main/examples/with-morpho) | Morpho Vaults USDC deposit/withdraw on Base Mainnet |
+| [`with-yield-xyz`](https://github.com/tkhq/sdk/tree/main/examples/with-yield-xyz) | Yield.xyz vaults deposit/withdraw across 75+ networks |
+| [`with-porto`](https://github.com/tkhq/sdk/tree/main/examples/with-porto) | Porto wallet upgrade and operations using API keys |
+| [`with-x402`](https://github.com/tkhq/sdk/tree/main/examples/with-x402) | Coinbase x402 payment protocol with embedded wallets |
+| [`with-jupiter`](https://github.com/tkhq/sdk/tree/main/examples/with-jupiter) | Solana token swaps using Jupiter Ultra Swap API |
+| [`with-breeze`](https://github.com/tkhq/sdk/tree/main/examples/with-breeze) | Solana USDC staking and yield management via Breeze API |
+| [`trading-runner`](https://github.com/tkhq/sdk/tree/main/examples/trading-runner/) | Multi-user Uniswap v3 trading demo with private key tags, user tags, and policies |
+| [`with-gnosis`](https://github.com/tkhq/sdk/tree/main/examples/with-gnosis/) | Create new Ethereum addresses, configure a 3/3 Gnosis safe, and create \+ execute a transaction from it |
## Policies & Access Control
-| Example | Description |
-| ----------------------------------------------------------------------------------- | -------------------------------- |
-| [`with-delegated`](https://github.com/tkhq/sdk/tree/main/examples/with-delegated/) | Delegated access setup examples |
+| Example | Description |
+| ---------------------------------------------------------------------------------- | ------------------------------- |
+| [`with-delegated`](https://github.com/tkhq/sdk/tree/main/examples/with-delegated/) | Delegated access setup examples |
## Smart Contracts & Automation
-| Example | Description |
-| ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
-| [`deployer`](https://github.com/tkhq/sdk/tree/main/examples/deployer/) | Compile and deploy a smart contract |
-| [`foundry`](https://github.com/tkhq/sdk/tree/main/examples/foundry) | Smart contract setup and broadcast from a Turnkey wallet using Foundry |
+| Example | Description |
+| ---------------------------------------------------------------------- | ---------------------------------------------------------------------- |
+| [`deployer`](https://github.com/tkhq/sdk/tree/main/examples/deployer/) | Compile and deploy a smart contract |
+| [`foundry`](https://github.com/tkhq/sdk/tree/main/examples/foundry) | Smart contract setup and broadcast from a Turnkey wallet using Foundry |
## Advanced & Utilities
-| Example | Description |
-| ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------- |
-| [`with-offline`](https://github.com/tkhq/sdk/tree/main/examples/with-offline/) | Stamp a Turnkey request and produce a signed URL to send it later |
-| [`kitchen-sink`](https://github.com/tkhq/sdk/tree/main/examples/kitchen-sink) | Playground scripts for common Turnkey requests via HTTP, sdk-server, and sdk-browser |
-| [`with-sdk-js`](https://github.com/tkhq/sdk/tree/main/examples/with-sdk-js) | Integration test suite for `@turnkey/core` and `@turnkey/react-wallet-kit` |
+| Example | Description |
+| ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ |
+| [`with-offline`](https://github.com/tkhq/sdk/tree/main/examples/with-offline/) | Stamp a Turnkey request and produce a signed URL to send it later |
+| [`kitchen-sink`](https://github.com/tkhq/sdk/tree/main/examples/kitchen-sink) | Playground scripts for common Turnkey requests via HTTP, sdk-server, and sdk-browser |
+| [`with-sdk-js`](https://github.com/tkhq/sdk/tree/main/examples/with-sdk-js) | Integration test suite for `@turnkey/core` and `@turnkey/react-wallet-kit` |
## Demos built with Turnkey
### Embedded Wallet Kit ([live link](https://wallets.turnkey.com/))
-A full-featured embedded wallet demo built with [`@turnkey/react-wallet-kit`](https://www.npmjs.com/package/@turnkey/react-wallet-kit), showcasing the latest Turnkey SDK. Includes passkey, email, and OAuth authentication, wallet creation, and more.
+A full-featured embedded wallet demo built with
+[`@turnkey/react-wallet-kit`](https://www.npmjs.com/package/@turnkey/react-wallet-kit), showcasing
+the latest Turnkey SDK. Includes passkey, email, and OAuth authentication, wallet creation, and
+more.
### Demo Embedded Wallet ([code](https://github.com/tkhq/demo-embedded-wallet), [live link](https://wallet.tx.xyz))
-A wallet application showing how users can register and authenticate using passkeys. Includes features such as:
+A wallet application showing how users can register and authenticate using passkeys. Includes
+features such as:
- User authentication with passkeys, email auth, and OAuth
- Creating new wallets and wallet accounts
@@ -152,45 +160,71 @@ See https://github.com/tkhq/demo-embedded-wallet for the code.
### React Native Wallet Kit ([code](https://github.com/tkhq/sdk/tree/main/examples/with-react-native-wallet-kit))
-A React Native app demonstrating how to use [`@turnkey/react-native-wallet-kit`](https://www.npmjs.com/package/@turnkey/react-native-wallet-kit) to authenticate users, create wallets, export wallets, sign messages, and more.
+A React Native app demonstrating how to use
+[`@turnkey/react-native-wallet-kit`](https://www.npmjs.com/package/@turnkey/react-native-wallet-kit)
+to authenticate users, create wallets, export wallets, sign messages, and more.
### Flutter demo app ([code](https://github.com/tkhq/dart-sdk/tree/main/examples/flutter-demo-app))
-A Flutter app that demonstrates how to use the Turnkey's Flutter packages to authenticate users, create wallets, export wallets, sign messages, and more
+A Flutter app that demonstrates how to use the Turnkey's Flutter packages to authenticate users,
+create wallets, export wallets, sign messages, and more
-
+
See https://github.com/tkhq/dart-sdk/tree/main/examples/flutter-demo-app for the code
### Demo Consumer Wallet ([code](https://github.com/tkhq/demo-consumer-wallet))
-A minimal consumer wallet app powered by Turnkey. Behind the scenes, it uses [`@turnkey/ethers`](https://www.npmjs.com/package/@turnkey/ethers) for signing and WalletConnect (v1) for accessing dapps.
+A minimal consumer wallet app powered by Turnkey. Behind the scenes, it uses
+[`@turnkey/ethers`](https://www.npmjs.com/package/@turnkey/ethers) for signing and WalletConnect
+(v1) for accessing dapps.
-
+
See https://github.com/tkhq/demo-consumer-wallet for the code.
### Demo Viem Passkeys with Gelato Relay ([code](https://github.com/gelatodigital/gelato-turnkey-passkeys-relay))
-This example demonstrates how to leverage Turnkey's secure key management and Gelato's battle-tested relay infrastructure to enable seamless, sponsored interactions with meta-transactions using the [`@turnkey/viem`](https://github.com/tkhq/sdk/tree/main/packages/viem) signer and [`@gelatonetwork/relay-sdk-viem`](https://github.com/gelatodigital/relay-sdk-viem).
+This example demonstrates how to leverage Turnkey's secure key management and Gelato's battle-tested
+relay infrastructure to enable seamless, sponsored interactions with meta-transactions using the
+[`@turnkey/viem`](https://github.com/tkhq/sdk/tree/main/packages/viem) signer and
+[`@gelatonetwork/relay-sdk-viem`](https://github.com/gelatodigital/relay-sdk-viem).
-
- 
-
+
#### How Infinex leverages Turnkey and Gelato
-Infinex, a platform designed to unify the decentralized ecosystem and applications under a single UX layer, eliminates the complexities of navigating fragmented crypto protocols. By integrating **Turnkey** and **Gelato**, Infinex delivers a seamless, secure, and cost-efficient experience for decentralized finance users.
+Infinex, a platform designed to unify the decentralized ecosystem and applications under a single UX
+layer, eliminates the complexities of navigating fragmented crypto protocols. By integrating
+**Turnkey** and **Gelato**, Infinex delivers a seamless, secure, and cost-efficient experience for
+decentralized finance users.
-- **Secure Key Management with Turnkey**: Infinex ensures private keys are securely managed within Turnkey's infrastructure, removing the need for traditional wallet pop-ups. This approach streamlines authentication through passkeys, offering a frictionless and secure user experience.
-- **Gasless Transactions with Gelato**: Leveraging Gelato's Relay (ERC-2771), Infinex enables fully **sponsored transactions**, allowing users to interact with decentralized applications without ever paying gas fees. This enhances accessibility and usability, ensuring that users can participate without holding or managing native blockchain tokens for fees.
+- **Secure Key Management with Turnkey**: Infinex ensures private keys are securely managed within
+ Turnkey's infrastructure, removing the need for traditional wallet pop-ups. This approach
+ streamlines authentication through passkeys, offering a frictionless and secure user experience.
+- **Gasless Transactions with Gelato**: Leveraging Gelato's Relay (ERC-2771), Infinex enables fully
+ **sponsored transactions**, allowing users to interact with decentralized applications without
+ ever paying gas fees. This enhances accessibility and usability, ensuring that users can
+ participate without holding or managing native blockchain tokens for fees.
-The synergy between Turnkey and Gelato allows Infinex to offer an intuitive, cost-free user experience while maintaining the highest standards of security and scalability.
+The synergy between Turnkey and Gelato allows Infinex to offer an intuitive, cost-free user
+experience while maintaining the highest standards of security and scalability.
### Multichain signing (Adamik demo)
-This [demo](https://turnkey-multichain.adamik.io/) shows how the Adamik API has integrated Turnkey to securely sign transactions across 60\+ blockchains.
+This [demo](https://turnkey-multichain.adamik.io/) shows how the Adamik API has integrated Turnkey
+to securely sign transactions across 60\+ blockchains.
diff --git a/production-checklist/production-checklist.mdx b/get-started/production-checklist.mdx
similarity index 86%
rename from production-checklist/production-checklist.mdx
rename to get-started/production-checklist.mdx
index 2a4b7190..dbbf9007 100644
--- a/production-checklist/production-checklist.mdx
+++ b/get-started/production-checklist.mdx
@@ -5,19 +5,19 @@ description: "This checklist contains recommendations and steps specifically for
## Production setup
-- Many of our customers prefer to maintain separate Development and Production [organizations](/concepts/organizations). If you choose to do so, ensure your production environment is referencing the correct organization ID.
+- Many of our customers prefer to maintain separate Development and Production [organizations](/features/organizations). If you choose to do so, ensure your production environment is referencing the correct organization ID.
- Ensure you have an active subscription via the Account Settings page in the Turnkey dashboard.
- If you are on an Enterprise plan, confirm your production organization ID with your account rep.
- Optionally, you may also generate keys using the [Turnkey CLI](/sdks/cli).
+ Optionally, you may also generate keys using the [Turnkey CLI](/sdks/introduction).
+
diff --git a/developer-reference/using-llms.mdx b/get-started/using-llms.mdx
similarity index 100%
rename from developer-reference/using-llms.mdx
rename to get-started/using-llms.mdx
diff --git a/getting-started.mdx b/getting-started.mdx
deleted file mode 100644
index 33755280..00000000
--- a/getting-started.mdx
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: Getting started
-description: Get started with Turnkey
-mode: wide
-sidebarTitle: Overview
----
-
-
-
-
-## How to get started on Embedded Business wallets with Turnkey
-
-1. **Set up Turnkey and end-user authentication:** Create a Turnkey org and configure how users will authenticate (e.g., email OTP, passkeys, OAuth).
-2. **Integrate Turnkey into the application and initialize the client:** Add Turnkey to the app so authentication, sessions, and wallet operations are available at runtime.
-3. **Provision a sub-organization per business or account:** Create a sub-org that represents the business entity and will contain its wallets, users, and policies.
-4. **Expose roles and permissions in the application UI:** Build UI that allows business users to manage roles (admin, operator, viewer) which map to Turnkey users and policies within the sub-org.
-5. **Enable business-grade wallet actions:** Surface wallet functionality (send/receive, signing, recovery) with policy-backed controls that reflect the business's internal approval structure.
-
-## Example policies your customers can configure
-
-| Need | RBAC Configuration |
-| :--- | :--- |
-| Treasury Manager initiates high-value transactions, requiring sign-off from both the CFO and Controller before processing. | **Multi-approval workflow:** Require 2+ approvers for high-value transactions |
-| The Controller or Head of Finance needs to maintain approved vendors and spending limits without manual review. | **Contractor and vendor payments:** Payments to allowlisted addresses with set spending limits. Manage the allowlist to add or remove recipients. |
-| Finance or Treasury needs to automatically execute recurring payments with set schedules, recipients, and amounts. | **Scheduled payments:** Restrict backend services to send recurring disbursements to approved recipients. |
-| Any changes to policies or admin permissions should require more than one executive approval. | **Organization admin / Root Quorum:** Require 2+ executives to approve changes to policies, permissions, or user access. |
-
-
-
-
- ```ts
- // Create role tags
- const { userTagId: financeTagId } = await apiClient.createUserTag({
- userTagName: "finance-team",
- userIds: [],
- });
-
- const { userTagId: operatorTagId } = await apiClient.createUserTag({
- userTagName: "operator",
- userIds: [],
- });
-
- // Add the Head of Finance with the finance role
- await apiClient.createUsers({
- users: [
- {
- userName: "Sarah Chen",
- userEmail: "sarah.chen@northstarlogistics.com",
- userTags: [financeTagId],
- apiKeys: [],
- authenticators: [],
- oauthProviders: [],
- },
- ],
- });
- ```
-
- Business users assign roles through your UI, and your application creates the corresponding tags and policies in their sub-org. Once roles are in place, create policies that reference them. See [Policy Quickstart](/concepts/policies/quickstart) for guidance.
- 
-
-
-## How to Get Started on Encryption Key Storage with Turnkey
-
-1. **Create encryption keypair:** Generate a P-256 keypair in Turnkey. The private key is stored in the secure enclave and never exposed.
-2. **Retrieve public key:** Fetch the public key to use for encryption on your side.
-3. **Encrypt data locally:** Use the public key to encrypt sensitive data and store it in your infrastructure.
-4. **Authenticate and export decryption key:** Authenticate the user and request the private key from Turnkey.
-5. **Decrypt and use locally:** Decrypt your stored bundles and use them locally, then clear sensitive data from memory.
-
-## Use Cases
-
-| Need | Configuration |
-| :--- | :--- |
-| Users need to recover wallets without managing backup keys themselves. | **User-controlled backup & recovery:** Encrypt recovery bundles on-device using Turnkey's public key, store encrypted bundles client-side, and gate decryption through user authentication ([social logins](/authentication/social-logins), [passkeys](/authentication/passkeys/introduction), [email OTP](/authentication/email)). |
-| Compliance or architecture requires sensitive material is not held by any single party. | **Distributed trust:** Store encrypted credentials, API keys, or secrets in your infrastructure. Gate decryption through Turnkey's policy engine and require quorum approval for key export in high-security scenarios. |
-
-
-
-
-## How to Get Started on Enterprise Disaster Recovery with Turnkey
-
-1. **Secure organization & policy setup**: Create your Turnkey org, configure the root quorum, and
- define recovery policies.
-2. **Set up the Turnkey SDK**: Integrate
- [React Wallet Kit](/sdks/react/using-embedded-wallets#importing-and-exporting-wallets) or
- [@turnkey/sdk-server](/embedded-wallets/code-examples/import#nodejs) into your application.
-3. **Import wallets**: Use handleImportWallet() to import wallet keys into Turnkey's secure enclave.
-
-## **Use Cases**
-
-| Need | Configuration |
-| :------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| A key holder becomes unavailable or a hardware wallet fails, requiring immediate recovery of treasury assets. | **Treasury recovery**: Import wallet keys into Turnkey's secure enclave with quorum-controlled access and policy-restricted fund sweeping. |
-| Migrating from another key management provider with no plaintext exposure during transit. | **Provider migration**: Encrypt keys to Turnkey's secure enclave on a hardened machine, import directly with full policy controls inherited immediately. |
-| Operations need to continue even if a primary signer or infrastructure goes down. | **Redundancy and failover**: Import backup copies of critical wallet keys into Turnkey so a secondary signing path is always available. |
-
-### 1. Secure Organization Setup and Recovery Policies
-
-Create a [Turnkey organization](https://app.turnkey.com/dashboard/auth/initial) and establish the
-security foundation for recovery operations:
-
-- Create dedicated recovery users with specific, limited permissions
-- Configure the [Root Quorum](/concepts/users/root-quorum) to require multiple approvers for
- sensitive operations
- - Require [quorum approval](/concepts/users/root-quorum) for high-value operations to prevent any
- single person from unilaterally moving recovered funds. This ensures no single credential
- compromise can trigger unauthorized recovery. See [Policy overview](/concepts/policies/overview)
- for setup guidance.
-
-- Distribute authenticators ([passkeys](/authentication/passkeys/introduction), YubiKeys) across
- geographic locations if possible
-- Define [policies](/concepts/policies/examples/signing-control) that restrict what can be done with
- recovered wallets.
-
-### 2. Set up the Turnkey SDK
-
-Integrate Turnkey into your application to enable wallet import and recovery operations. The
-[NodeJS server SDK](https://github.com/tkhq/sdk/tree/main/examples/import-in-node) is well oriented
-to handle the entire import flow, including encryption and secure transport.
-
-```ts
-import { Turnkey } from "@turnkey/sdk-server";
-import { encryptPrivateKeyToBundle, encryptWalletToBundle } from "@turnkey/crypto";
-
-const initResult = await turnkeyClient.apiClient().initImportWallet({
- userId,
-});
-
-const walletBundle = await encryptWalletToBundle({
- mnemonic,
- importBundle: initResult.importBundle,
- userId,
- organizationId,
-});
-```
-
-### 3. Import Wallets
-
-Use [importWallet()](/generated-docs/core/turnkey-client-import-wallet) to import wallet keys into
-Turnkey's secure enclave. In the last step the SDK encrypts the mnemonic or private key to Turnkey's
-enclave public key using [HPKE (Hybrid Public Key Encryption)](/security/enclave-secure-channels),
-and now transmits the encrypted bundle. The enclave decrypts and stores the key material.
-
-```ts
-const walletImportResult = await turnkeyClient.apiClient().importWallet({
- userId: userId,
- walletName: "Your imported wallet!",
- encryptedBundle: walletBundle,
- accounts: [],
-});
-```
-
-All fund movements are logged with cryptographic signatures, providing a complete audit trail of the
-recovery operation.
-
-## The Result: Enterprise-grade Key Recovery
-
-Turnkey transforms enterprise disaster recovery from a high-risk, manual operation into a secure,
-verifiable process. Import wallet keys directly into Turnkey's secure enclave and gain immediate
-operational capability with full policy controls:
-
-- **Cryptographic guarantees**: Key material is protected by secure enclaves and end-to-end
- encryption
-- **Organizational controls**: Quorum policies prevent unilateral action on sensitive operations
-- **Operational flexibility**: Support for all major chains and key types through a unified
- interface
-- **Audit compliance**: Every operation is logged with cryptographic signatures
-
-## Resources
-
-Explore the complete implementation in our
-[GitHub 'Disaster Recovery' example](https://github.com/tkhq/sdk/tree/main/examples/disaster-recovery).
-
-- [Import Wallets Guide](/wallets/import-wallets)
-- [Export Wallets Guide](/wallets/export-wallets)
-- [Root Quorum Configuration](/concepts/users/root-quorum)
-- [Secure Enclaves Overview](/security/secure-enclaves)
-- [Enclave Secure Channels](/security/enclave-secure-channels)
diff --git a/products/key-management/examples/overview.mdx b/products/key-management/examples/overview.mdx
deleted file mode 100644
index 63edf2db..00000000
--- a/products/key-management/examples/overview.mdx
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: "Code examples"
-sidebarTitle: "Overview"
-mode: wide
----
-
-
+
diff --git a/sdks/advanced/turnkey-client.mdx b/sdks/advanced/turnkey-client.mdx
index d33a136e..0f2eeb78 100644
--- a/sdks/advanced/turnkey-client.mdx
+++ b/sdks/advanced/turnkey-client.mdx
@@ -63,7 +63,7 @@ Currently Turnkey provides 3 stampers:
* applications signing requests with API keys should use [`@turnkey/api-key-stamper`](/sdks/advanced/api-key-stamper)
* applications that need to sign requests within an iframe, particularly when handling sensitive operations like Auth, or Key or Wallet Export, should use the [`@turnkey/iframe-stamper`](/sdks/advanced/iframe-stamper).
-You can also implement the TStamper interface yourself. For more information on implementing a custom stamper checkout the [API Design](/developer-reference/api-overview/intro) docs.
+You can also implement the TStamper interface yourself. For more information on implementing a custom stamper checkout the [API Design](/api-reference/overview/intro) docs.
### Types
@@ -97,6 +97,6 @@ const apiPrivateKey = process.env.TURNKEY_API_PRIVATE_KEY;
// Initialize the API key stamper
const stamper = new ApiKeyStamper({ apiPublicKey, apiPrivateKey });
-// Initialize the Turnkey client and then you're ready to use the Turnkey client! 🎉
+// Initialize the Turnkey client and then you're ready to use the Turnkey client.
const client = new TurnkeyClient({ baseUrl }, stamper);
```
diff --git a/sdks/advanced/wallet-stamper.mdx b/sdks/advanced/wallet-stamper.mdx
index 13133d93..649e1d6a 100644
--- a/sdks/advanced/wallet-stamper.mdx
+++ b/sdks/advanced/wallet-stamper.mdx
@@ -168,7 +168,7 @@ const walletStamper = new WalletStamper(new SolanaWallet());
// Instantiate the TurnkeyClient with the WalletStamper
const client = new TurnkeyClient({ baseUrl: BASE_URL }, walletStamper);
-// You're now ready to make requests to Turnkey's API 🎉
+// You're now ready to make requests to Turnkey's API.
```
## Conclusion
diff --git a/sdks/advanced/webauthn-stamper.mdx b/sdks/advanced/webauthn-stamper.mdx
index b4d7921b..de84d53a 100644
--- a/sdks/advanced/webauthn-stamper.mdx
+++ b/sdks/advanced/webauthn-stamper.mdx
@@ -6,7 +6,7 @@ title: "WebauthnStamper"
The [`@turnkey/webauthn-stamper`](https://www.npmjs.com/package/@turnkey/webauthn-stamper) package is used for stamping requests made to Turnkey's API with WebAuthn credentials, but specifically for use with passkeys.
-For more information on passkeys and WebAuthn refer to [this section](/authentication/passkeys/introduction).
+For more information on passkeys and WebAuthn refer to [this section](/features/authentication/passkeys/introduction).
## Installing
@@ -92,7 +92,7 @@ type TWebauthnStamperConfig = {
type UserVerificationRequirement = "discouraged" | "preferred" | "required";
```
-Refer to our guide on [using passkeys](/authentication/passkeys/options#userverification) for more information on this type and its usage.
+Refer to our guide on [using passkeys](/features/authentication/passkeys/options#userverification) for more information on this type and its usage.
##### `PublicKeyCredentialDescriptor`
@@ -104,7 +104,7 @@ interface PublicKeyCredentialDescriptor {
}
```
-Refer to our guide on [using passkeys](/authentication/passkeys/options#allowcredentials) for more information on this type and its usage.
+Refer to our guide on [using passkeys](/features/authentication/passkeys/options#allowcredentials) for more information on this type and its usage.
#### Example
diff --git a/sdks/cli.mdx b/sdks/cli.mdx
deleted file mode 100644
index 0ef0b8da..00000000
--- a/sdks/cli.mdx
+++ /dev/null
@@ -1,113 +0,0 @@
----
-title: "Using the CLI"
-description: "This quickstart will guide you through Turnkey’s onboarding, adding an API key, creating a wallet, and signing your first Ethereum transaction."
-sidebarTitle: "CLI"
----
-
-## Create your Turnkey organization
-
-- Visit [app.turnkey.com/dashboard/auth/initial](https://app.turnkey.com/dashboard/auth/initial) and enter your email address
-- Confirm your email by clicking on the link inside of the confirmation email
-- Follow the prompts to add your first authenticator and create your organization
-
-## Find your organization ID
-
-All API requests require an organization ID. Yours can be located in the user dropdown menu at the top right corner of the dashboard.
-
-
- 
-
-
-For convenience, it's worth setting this as a permanent shell variable:
-
-```bash
-export ORGANIZATION_ID="
-
-
-Click on "Create API keys" and follow the prompts to add the generated public API key. You'll be required to authenticate with the same authenticator used during onboarding. After this succeeds, you should be all set to interact with our API.
-
-NOTES:
-
-- if you would like to manually copy your locally stored public/private API key files (e.g. `key.public`, `key.private`), you will have to save the files without newlines (which occupy extra bytes). For example, for VIM, use `:set binary noeol` or `:set binary noendofline` before writing.
-- only P-256 keys (API_KEY_CURVE_P256) are currently supported
-
-## Create a wallet
-
-Wallets are collections of cryptographic key pairs typically used for sending and receiving digital assets. To create one, we need to provide a name:
-
-```bash
-turnkey wallets create --name default --key-name quickstart
-```
-
-## Create an Ethereum account
-
-To create a cryptographic key pair on our new Wallet, we need to pass our desired address format:
-
-```bash
-turnkey wallets accounts create --wallet default --address-format ADDRESS_FORMAT_ETHEREUM --key-name quickstart
-```
-
-This command will produce an Ethereum address (e.g. `0x08cb1216C95149DF66978b574E484869512CE2bF`) that we'll need to sign a transaction. You can see your new Wallet account with:
-
-```bash
-turnkey wallets accounts list --wallet default --key-name quickstart
-```
-
-## Sign a transaction
-
-Now you can sign an Ethereum transaction with this new address with our [`sign_transaction` endpoint](/api-reference/signing/sign-transaction). Make sure to replace the `unsignedTransaction` below with your own. You can use our [simple transaction generator](https://build.tx.xyz) if you need a quick transaction for testing:
-
-```json
-turnkey request --path /public/v1/submit/sign_transaction --body '{
- "timestampMs": "'"$(date +%s)"'000",
- "type": "ACTIVITY_TYPE_SIGN_TRANSACTION_V2",
- "organizationId": "'"$ORGANIZATION_ID"'",
- "parameters": {
- "type": "TRANSACTION_TYPE_ETHEREUM",
- "signWith": "
+
diff --git a/wallets/wagmi.mdx b/sdks/web3/wagmi.mdx
similarity index 99%
rename from wallets/wagmi.mdx
rename to sdks/web3/wagmi.mdx
index 20501a68..f9e394e4 100644
--- a/wallets/wagmi.mdx
+++ b/sdks/web3/wagmi.mdx
@@ -3,8 +3,6 @@ title: Integrating an embedded wallet with Wagmi
---
-# Introduction
-
Turnkey wallets are embedded, web-based wallets that differ from injected wallets (like MetaMask).
While injected wallets store private keys locally and decrypt them using a password to sign transactions,
embedded wallets rely on UI-based authentication to access private keys that are securely stored and
@@ -358,7 +356,7 @@ At this point you can:
2. Integrate the minimal provider + connector in a dApp.
3. Click **Connect Wallet** in the dApp → the pop-up opens → authenticate → dApp receives the account.
-🎉 You now have a working end-to-end connection flow! Next we'll extend both the wallet UI and the provider to support signing transactions and messages.
+You now have a working end-to-end connection flow. Next we'll extend both the wallet UI and the provider to support signing transactions and messages.
## Add transaction and message signing
diff --git a/security/enclave-secure-channels.mdx b/security/enclave-secure-channels.mdx
index 041bfa3a..f6394e8b 100644
--- a/security/enclave-secure-channels.mdx
+++ b/security/enclave-secure-channels.mdx
@@ -1,6 +1,6 @@
---
title: "Enclave to end-user secure channels"
-sidebarTitle: "Enclave Secure Channels"
+sidebarTitle: "Enclave secure channels"
---
Turnkey does not trust anything running outside of secure enclaves. See [our approach](/security/our-approach) for more details. When enclaves and end-users need to exchange private information, we rely on a protocol based on [HPKE](https://datatracker.ietf.org/doc/html/rfc9180) to establish a **secure channel**.
diff --git a/security/non-custodial-key-mgmt.mdx b/security/non-custodial-key-mgmt.mdx
index 0a6d5e02..b77155fe 100644
--- a/security/non-custodial-key-mgmt.mdx
+++ b/security/non-custodial-key-mgmt.mdx
@@ -16,4 +16,4 @@ Turnkey does not store unencrypted private keys, but rather persists encrypted p
## Non-custodial wallets for end users
-In a wallet-as-a-service implementation model, it is possible for you, as a Turnkey customer, to configure your organization in a way that limits access to your end users’ funds and private keys. When a new end user signs up to your app, you will need to create a separate Turnkey sub-organization, user, and private key for that end user, accessible only by the end user’s secret (e.g., API key or Passkey credentials). With this implementation, only your end user will be able to authorize Turnkey to process a signature request by providing their secret. Use of the private key is limited to the end user via their secret. When a signature request is initiated by the end user’s secret, Turnkey’s functionality is limited to processing the request based on any policy rules that have been set, and returning the signed transaction to you for broadcast on chain.
+In a wallet-as-a-service implementation model, it is possible for you, as a Turnkey customer, to configure your organization in a way that limits access to your end users’ funds and private keys. When a new end user signs up to your app, you will need to create a separate Turnkey sub-organization, user, and private key for that end user, accessible only by the end user’s secret (e.g., API key or Passkey credentials). With this implementation, only your end user will be able to authorize Turnkey to process a signature request by providing their secret. Use of the private key is limited to the end user via their secret. When a signature request is initiated by the end user’s secret, Turnkey’s functionality is limited to processing the request based on any policy rules that have been set, and returning the signed transaction to you for broadcast onchain.
diff --git a/security/overview.mdx b/security/overview.mdx
new file mode 100644
index 00000000..849399e8
--- /dev/null
+++ b/security/overview.mdx
@@ -0,0 +1,30 @@
+---
+title: Security & architecture
+sidebarTitle: Overview
+description: "Learn how Turnkey achieves innovative, cloud scale, no single point of failure security."
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx'
+
+Turnkey is the first verifiable key management system of its kind, securing millions of wallets and private keys for a wide variety of use cases.
+Turnkey's security architecture ensures that raw private keys are never exposed to Turnkey, your software, or your team.
+We provide end-to-end private key generation and access control within secure enclaves, with strong isolation guarantees and
+cryptographic attestation proving that only authorized code is running. Our custom-built operating system, QuorumOS,
+minimizes attack surface and enables reproducible, auditable deployments. From hardware-backed trust to multi-factor access controls,
+every layer of Turnkey's architecture is designed to be secure, verifiable, and developer-friendly by default. Our whitepaper covers our
+holistic security model in-depth, and speaks to our vision for building verifiable key management infrastructure. Learn more about our approach to security here.
+
+
+
diff --git a/products/company-wallets/features/security/remote-attestation.mdx b/security/remote-attestation.mdx
similarity index 100%
rename from products/company-wallets/features/security/remote-attestation.mdx
rename to security/remote-attestation.mdx
diff --git a/security/shared-responsibility-model.mdx b/security/shared-responsibility-model.mdx
index d9044641..4022336e 100644
--- a/security/shared-responsibility-model.mdx
+++ b/security/shared-responsibility-model.mdx
@@ -2,7 +2,6 @@
title: "Turnkey shared responsibility model"
---
-# Introduction
When integrating your product with Turnkey, it is critical to understand which security tasks are Turnkey’s responsibility, and which tasks are your responsibility.
Turnkey provides secure, scalable, and programmable crypto infrastructure. Flexibility is at the core of our product, which means you have the freedom to integrate Turnkey in ways that may or may not fully meet your product’s security requirements. As detailed below, you are responsible for securing both your Turnkey organization, and your integration with Turnkey.
diff --git a/security/turnkey-verified.mdx b/security/turnkey-verified.mdx
index 57064277..2b84abe1 100644
--- a/security/turnkey-verified.mdx
+++ b/security/turnkey-verified.mdx
@@ -2,7 +2,7 @@
title: "Turnkey Verified"
---
-Turnkey Verified is a new feature launched in Turnkey's [dashboard](https://app.turnkey.com) and [Embedded Wallet Kit](/reference/embedded-wallet-kit).
+Turnkey Verified is a new feature launched in Turnkey's [dashboard](https://app.turnkey.com) and [Embedded Wallet Kit](/solutions/embedded-wallets/integration-guide/react/getting-started).
As outlined in our [Whitepaper](https://whitepaper.turnkey.com/foundations#boot-proofs-and-app-proofs), Turnkey deploys software in secure enclaves and can remotely attest to the software running inside of them. We've done this since day one, internally: remote attestations are at the core of our deployment process and are a crucial tool to ensure Turnkey operators are provisioning enclaves with the correct configuration.
@@ -44,13 +44,13 @@ Verifying an App Proof thus involves 3 simple steps:
* Verify the App Proof signature validity (standard P-256 signature verification)
* Parse the content of the App Proof payload (JSON) and use the data within it to verify claimed facts (see below for an example).
-# Use cases
+## Use cases
You can enable App Proofs for any [activity](/api-reference/activities/overview). Turnkey Verified currently supports two App Proof types, each verifying a different operation performed inside a secure enclave.
### Address derivation proofs
-Address derivation proofs verify that a crypto address was correctly derived by Turnkey's **signer application**. These proofs are generated when new wallets are created. Turnkey verified will automatically fetch and verify proofs for you when new wallets are created through Turnkey's [Embedded Wallet Kit](/reference/embedded-wallet-kit) or via Turnkey's [dashboard](https://app.turnkey.com).
+Address derivation proofs verify that a crypto address was correctly derived by Turnkey's **signer application**. These proofs are generated when new wallets are created. Turnkey verified will automatically fetch and verify proofs for you when new wallets are created through Turnkey's [Embedded Wallet Kit](/solutions/embedded-wallets/integration-guide/react/getting-started) or via Turnkey's [dashboard](https://app.turnkey.com).
The payload:
```json
diff --git a/security/verifiable-data.mdx b/security/verifiable-data.mdx
index fa0dfc64..b957e694 100644
--- a/security/verifiable-data.mdx
+++ b/security/verifiable-data.mdx
@@ -1,5 +1,5 @@
---
-title: "Verifiable Data"
+title: "Verifiable data"
---
Enclave applications in Turnkey's infrastructure are stateless, meaning there is no persistent data held behind the enclave boundary. Instead, data is stored in a PostgreSQL instance in our primary AWS account. Before any enclave application operates on account data, it first verifies that the data has been recently notarized by Turnkey's notarizer. A recent stamp could be the result of an update or be initiated by the heartbeat service.
diff --git a/snippets/feature-card.mdx b/snippets/feature-card.mdx
new file mode 100644
index 00000000..c05867ee
--- /dev/null
+++ b/snippets/feature-card.mdx
@@ -0,0 +1,38 @@
+export const FeatureCard = ({ title, description, icon, logo, href }) => {
+ return (
+
+
+
+ {logo ? (
+ 
+ ) : (
+
+ )}
+
+
+
+ );
+};
diff --git a/snippets/shared/export-wallets.mdx b/snippets/shared/export-wallets.mdx
index 6e139a3f..a51a0f44 100644
--- a/snippets/shared/export-wallets.mdx
+++ b/snippets/shared/export-wallets.mdx
@@ -1,6 +1,6 @@
---
title: "Export Wallets and Keys"
-description: "Turnkey's export functionality allows your end users to backup or transfer a [Wallet](/concepts/wallets) by securely viewing the wallet's [mnemonic phrase](https://learnmeabitcoin.com/technical/mnemonic). We engineered this feature to ensure that the user can export their mnemonic without exposing the mnemonic itself to Turnkey or your application."
+description: "Turnkey's export functionality allows your end users to backup or transfer a [Wallet](/features/wallets) by securely viewing the wallet's [mnemonic phrase](https://learnmeabitcoin.com/technical/mnemonic). We engineered this feature to ensure that the user can export their mnemonic without exposing the mnemonic itself to Turnkey or your application."
mode: wide
---
@@ -21,4 +21,4 @@ See the [Enclave to end-user secure channel](/security/enclave-secure-channels)
## Implementation Guides
-See [Code Examples](/embedded-wallets/code-examples/export) for more details.
+See [Code Examples](/solutions/embedded-wallets/integration-guide/react/using-embedded-wallets) for more details.
diff --git a/snippets/shared/fiat-on-ramp.mdx b/snippets/shared/fiat-on-ramp.mdx
index 78ca3a89..cdcd7203 100644
--- a/snippets/shared/fiat-on-ramp.mdx
+++ b/snippets/shared/fiat-on-ramp.mdx
@@ -110,4 +110,4 @@ The Coinbase demo is running in a sandbox environment which means:
## Implementation Guide
-See the [Fiat Onramp Code Example](/embedded-wallets/code-examples/fiat-on-ramp) for more details on how to implement.
+See the [Fiat Onramp Code Example](/features/transaction-management/fiat-on-ramp) for more details on how to implement.
diff --git a/snippets/shared/import-wallets.mdx b/snippets/shared/import-wallets.mdx
index 164907bc..ecc82e23 100644
--- a/snippets/shared/import-wallets.mdx
+++ b/snippets/shared/import-wallets.mdx
@@ -1,6 +1,6 @@
---
title: "Import Wallets and Keys"
-description: "Turnkey's import functionality allows your end users to securely transfer a [Wallet](/concepts/wallets) or a [Private Key](/concepts/wallets#private-keys) onto the Turnkey platform via CLI or an embedded iframe. We engineered this feature to ensure that the user can import their mnemonic or private key into a Turnkey secure enclave without exposing it to Turnkey or your application."
+description: "Turnkey's import functionality allows your end users to securely transfer a [Wallet](/features/wallets) or a [Private Key](/features/wallets#private-keys) onto the Turnkey platform via CLI or an embedded iframe. We engineered this feature to ensure that the user can import their mnemonic or private key into a Turnkey secure enclave without exposing it to Turnkey or your application."
mode: wide
---
@@ -21,4 +21,4 @@ See the [Enclave to end-user secure channel](/security/enclave-secure-channels)
## Implementation Guides
-See [Code Examples](/embedded-wallets/code-examples/import) for more details.
+See [Code Examples](/solutions/embedded-wallets/integration-guide/react/using-embedded-wallets) for more details.
diff --git a/snippets/shared/networks-links.mdx b/snippets/shared/networks-links.mdx
index bb095883..a9e5c6f5 100644
--- a/snippets/shared/networks-links.mdx
+++ b/snippets/shared/networks-links.mdx
@@ -1,137 +1,55 @@
-
+ ) : (
+
+ )}
+
+
+
+
+ {title}
+
+ {description && (
+
+ {description}
+
+ )}
+
+
+ {logo ? (
+
+ ) : (
+
+ )}
+
+
+
+ );
+
+ return (
+
+ ) : (
+
+ )}
+
+
+
+
+ {title}
+
+
+
+ );
+};
diff --git a/snippets/shared/policy-engine.mdx b/snippets/shared/policy-engine.mdx
index 2c3e4cf4..c113b2b3 100644
--- a/snippets/shared/policy-engine.mdx
+++ b/snippets/shared/policy-engine.mdx
@@ -8,7 +8,7 @@ sidebarTitle: "Policy Engine"
Our policies are defined using **JSON**. The `effect` determines if an activity should be allowed or denied based on the evaluation of the `consensus` and `condition` fields.
-`consensus` and `condition` are composed of ergonomic expressions written in our [policy language](/concepts/policies/language) that must evaluate to a `bool`. `consensus` determines which user(s) may take an action (e.g. a given user ID). `condition` determines the conditions under which the policy applies (e.g. signing with a specific wallet). These fields can be used alone or together.
+`consensus` and `condition` are composed of ergonomic expressions written in our [policy language](/features/policies/language) that must evaluate to a `bool`. `consensus` determines which user(s) may take an action (e.g. a given user ID). `condition` determines the conditions under which the policy applies (e.g. signing with a specific wallet). These fields can be used alone or together.
#### See below for an example policy that allows a single user to send transactions to a single address
diff --git a/snippets/shared/send-solana-tx-sdk-overview.mdx b/snippets/shared/send-solana-tx-sdk-overview.mdx
index 33bd1a88..204df866 100644
--- a/snippets/shared/send-solana-tx-sdk-overview.mdx
+++ b/snippets/shared/send-solana-tx-sdk-overview.mdx
@@ -21,11 +21,11 @@ You can sign and broadcast Solana transactions in two primary ways:
This is the right choice for Node.js backends. It exposes the same methods via the server SDK client.
-This page walks you through the React flow with full code examples. For using `@turnkey/core` directly, see [Sending Sponsored Transactions](/company-wallets/code-examples/sending-sponsored-transactions).
+This page walks you through the React flow with full code examples. For using `@turnkey/core` directly, see [Sending Sponsored Transactions](/features/transaction-management/broadcasting).
+ 
+ 
+
+
+ );
+};
diff --git a/solutions/company-wallets/agentic-wallets.mdx b/solutions/company-wallets/agentic-wallets.mdx
new file mode 100644
index 00000000..f20f1a1f
--- /dev/null
+++ b/solutions/company-wallets/agentic-wallets.mdx
@@ -0,0 +1,236 @@
+---
+title: "Agentic Wallets"
+description: "Give AI agents scoped signing authority over company wallets with policy-enforced access control, spending caps, and multi-party consensus for high-value actions."
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx'
+import { SolutionCard } from '/snippets/solution-card.mdx'
+
+This guide covers the key implementation decisions for giving AI agents secure access to company wallets, then walks through provisioning an agent end-to-end: creating a scoped wallet, assigning a non-root agent user, and defining policies that constrain exactly what the agent can sign. For basic signing, start with the [Quickstart](/solutions/company-wallets/quickstart).
+
+## Turnkey agent skills
+
+[Agent Skills](/get-started/ai-skills) let you operate on Turnkey directly through an AI assistant, no application code required. The agent provisioning workflow skill lets you quickly create a wallet scoped for agent usage through your AI assistant. You can then equip your agent with skills so it can autonomously operate within the boundaries you've configured.
+
+## Agent personas
+
+Turnkey supports different agent roles through policy composition:
+
+| Persona | What it can do | Policy approach |
+| :--- | :--- | :--- |
+| **Worker** | Signs transactions on a designated wallet | ALLOW with wallet scope + destination/function/value constraints |
+| **Observer** | Read-only access (balance checks, activity monitoring) | No policies needed; default-deny prevents signing. Add explicit DENY if org has shared ALLOWs. |
+| **Approver** | Reviews and approves other agents' transactions | Narrow ALLOW for `APPROVE_ACTIVITY` and `REJECT_ACTIVITY` only. Must NOT have signing permissions. |
+
+These personas can be composed for multi-agent systems. For example, a worker agent proposes trades, an approver agent validates them against risk models, and a human admin retains override authority for high-value actions.
+
+## Key implementation decisions
+
+| Decision | What to consider |
+| :--- | :--- |
+| Wallet scope | Dedicate a wallet (or specific accounts) to the agent. Never share wallets between agents with different trust levels. |
+| Destination allowlist | Restrict which addresses the agent can send to (e.g., only a treasury address, only a specific DEX router) |
+| Spending caps | Bound transaction values per-signing to limit blast radius if the agent misbehaves |
+| Function restrictions | For smart contract interactions, restrict to specific function selectors or [upload the ABI](/features/policies/smart-contract-interfaces) for argument-level control |
+| Consensus requirements | For high-value actions, require both the agent and a human (or another agent) to approve before the enclave signs |
+| Key management | Store agent API keys in a secrets manager. Plan for rotation without downtime. Use short-lived keys where viable. |
+| Transaction management | Enterprise customers can use Turnkey's [transaction management](/features/transaction-management) to offload gas sponsorship, nonce management, and broadcasting — so agents only need to handle signing logic. |
+
+## Example: autonomous trading agent
+
+An AI agent that analyzes market data and executes trades on a DEX needs scoped signing authority: it should only be able to call specific router functions on approved contracts, with spending limits and human oversight for large trades.
+
+| Need | How Turnkey solves it |
+| :--- | :--- |
+| Agent must never access the private key | Keys stay in the [secure enclave](/security/secure-enclaves); the agent authenticates via API key and receives signatures only |
+| Signing must be restricted to approved contracts | Policies target specific contract addresses and function selectors |
+| Large trades need human approval | Consensus expressions require both the agent and a human approver for transactions above a threshold |
+| Must support multiple chains | One agent user with chain-specific policies (EVM, SVM, etc.) covering each network |
+| Must be revocable instantly | Delete the agent user to permanently and immediately revoke all access |
+
+### Implementation steps
+
+
+
+
+
+
+ {title}
+
+
+ {description}
+
+
+
diff --git a/sdks/golang.mdx b/solutions/company-wallets/integration-guide/golang.mdx
similarity index 100%
rename from sdks/golang.mdx
rename to solutions/company-wallets/integration-guide/golang.mdx
diff --git a/sdks/javascript-server.mdx b/solutions/company-wallets/integration-guide/javascript-server.mdx
similarity index 81%
rename from sdks/javascript-server.mdx
rename to solutions/company-wallets/integration-guide/javascript-server.mdx
index 8dcb65d4..d988ffee 100644
--- a/sdks/javascript-server.mdx
+++ b/solutions/company-wallets/integration-guide/javascript-server.mdx
@@ -1,14 +1,21 @@
---
title: "TypeScript server"
-description: "The [`@turnkey/sdk-server`](https://www.npmjs.com/package/@turnkey/sdk-server) package exposes functionality that lets developers build server-side functionality for applications that interact with the Turnkey API."
-sidebarTitle: "TypeScript | Server"
+description:
+ "The [`@turnkey/sdk-server`](https://www.npmjs.com/package/@turnkey/sdk-server) package exposes
+ functionality that lets developers build server-side functionality for applications that interact
+ with the Turnkey API."
+sidebarTitle: "TypeScript server"
---
## Overview
-It exposes a ready-made API client class which manages the process of constructing requests to the Turnkey API and authenticating them with a valid API key. Furthermore, it exposes API proxies that forward requests from your application's client that need to be signed by parent organizations API key.
+It exposes a ready-made API client class which manages the process of constructing requests to the
+Turnkey API and authenticating them with a valid API key. Furthermore, it exposes API proxies that
+forward requests from your application's client that need to be signed by parent organizations API
+key.
-Use the [`@turnkey/sdk-server`](https://www.npmjs.com/package/@turnkey/sdk-server) package to handle server-side interactions for applications that interact with the Turnkey API.
+Use the [`@turnkey/sdk-server`](https://www.npmjs.com/package/@turnkey/sdk-server) package to handle
+server-side interactions for applications that interact with the Turnkey API.
## Installation
@@ -63,7 +70,8 @@ The root organization that requests will be made from unless otherwise specified
required
>
-The base URL that API requests will be sent to (use [https://api.turnkey.com](https://api.turnkey.com) when making requests to Turnkey's API)
+The base URL that API requests will be sent to (use
+[https://api.turnkey.com](https://api.turnkey.com) when making requests to Turnkey's API)
+
+
+## Ready to build?
+
+- [Company Wallets Quickstart](/solutions/company-wallets/quickstart) -- set up your organization, create wallets, and sign your first transaction
+- [Policy Quickstart](/features/policies/quickstart) -- define access controls and signing rules for your team
+- [SDK Reference](/sdks/introduction) -- server SDKs for TypeScript, Go, Ruby, Python, and Rust
diff --git a/solutions/company-wallets/payment-orchestration.mdx b/solutions/company-wallets/payment-orchestration.mdx
new file mode 100644
index 00000000..89a947b5
--- /dev/null
+++ b/solutions/company-wallets/payment-orchestration.mdx
@@ -0,0 +1,172 @@
+---
+title: "Payment Orchestration"
+description: "Build automated sweep, deposit, and treasury flows with policy-enforced access control and gas sponsorship."
+mode: wide
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx'
+import { SolutionCard } from '/snippets/solution-card.mdx'
+
+Move funds programmatically across deposit, omnibus, and cold wallets with sub-100ms signing and policy-enforced access control at every transaction. For a basic signing walkthrough, start with the [Quickstart](/solutions/company-wallets/quickstart).
+
+This guide covers the key implementation decisions for company wallet payment flows, then walks through a production example end-to-end: creating per-user deposit addresses, sweeping those deposits into an omnibus wallet with gas sponsorship, and gating treasury outflows with multi-party approval.
+
+## Powered by Turnkey
+
+Leading platforms use Turnkey to deliver onchain payment rails at scale:
+
+- [**Squads**](https://www.turnkey.com/customers/how-squads-improves-ux-and-accounting-efficiency-with-turnkey) improved UX and accounting efficiency for multisig treasury management.
+- [**Flutterwave**](https://flutterwave.com/us/blog/flutterwave-partners-with-turnkey-to-power-secure-stablecoin-wallets-for-customers) powers secure stablecoin wallets for customers across Africa.
+
+## Key implementation decisions
+
+| Decision | What to consider |
+| :--- | :--- |
+| Wallet architecture | Single HD wallet with many accounts (cost-efficient, shared seed) vs separate wallets per function (deposits, omnibus, cold) |
+| Deposit addressing | Per-user deposit addresses via `createWalletAccounts` at no extra cost |
+| Sweep strategy | Policy-enforced sweeps restricting deposit addresses to a single omnibus destination |
+| Gas management | [Sponsored transactions](/features/transaction-management/broadcasting) (`sponsor: true`) eliminate the need to fund each deposit address for gas |
+| Chain coverage | EVM and SVM require separate policies due to different transaction models |
+| Hot wallet controls | Automated API key user with policies scoping exactly which transfers are allowed |
+| Treasury controls | Multi-party approval via [consensus expressions](/features/policies/quickstart) (e.g., 2-of-N ops team) |
+| Cold storage transfers | Policy-gated with parsed calldata for token transfers, or [upload the contract ABI](/features/policies/smart-contract-interfaces) for full parsing |
+
+## Example: custodial payment processing
+
+Exchanges and custodial payment processors are common examples requiring highly scalable, highly secure onchain systems.
+
+
+
+| Need | How Turnkey solves it |
+| :--- | :--- |
+| All users have a unique deposit address | Wallet accounts are efficiently created and controlled within a Turnkey organization |
+| Access to all wallets must be strictly permissioned | Policies enforce RBAC and least-privilege for all signing actions |
+| Keys must never be exposed | Keys remain in the [secure enclave](/security/secure-enclaves); only signatures are returned |
+| Must support automation and human review | Policies allow automation for routine tasks and require multi-party consensus for sensitive ones |
+| Must move funds efficiently | [Transaction sponsorship](/features/transaction-management/broadcasting) eliminates the cost of funding thousands of deposit addresses for gas |
+
+### Implementation steps
+
+
+
diff --git a/solutions/company-wallets/quickstart.mdx b/solutions/company-wallets/quickstart.mdx
new file mode 100644
index 00000000..bd807e3f
--- /dev/null
+++ b/solutions/company-wallets/quickstart.mdx
@@ -0,0 +1,158 @@
+---
+title: "Company Wallets quickstart"
+description: "Get from zero to a signed transaction with Turnkey's Company Wallets. Initialize the server SDK, create a wallet, and sign your first Ethereum transaction using Viem or Ethers."
+sidebarTitle: "Quickstart"
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx'
+import { SolutionCard } from '/snippets/solution-card.mdx'
+
+## Prerequisites
+
+This guide assumes you've completed the steps to create an account, organization, and API keypair as described in the [account setup](/get-started/quickstart) section. This guide uses the TypeScript server SDK (`@turnkey/sdk-server`). For other languages, see [Server SDKs](/sdks/introduction).
+
+## Installation
+
+Install the server SDK and your preferred Ethereum library:
+
+
+
diff --git a/solutions/company-wallets/smart-contract-management.mdx b/solutions/company-wallets/smart-contract-management.mdx
new file mode 100644
index 00000000..d4c9b0dd
--- /dev/null
+++ b/solutions/company-wallets/smart-contract-management.mdx
@@ -0,0 +1,124 @@
+---
+title: "Smart Contract Management"
+description: "Secure the full smart contract lifecycle with policy-enforced deployment, function-level access control, and safe upgrade workflows."
+mode: wide
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx'
+import { SolutionCard } from '/snippets/solution-card.mdx'
+
+This guide covers the key implementation decisions for securing smart contract operations, then walks through the contract lifecycle end-to-end: permissioned deployment, function-level interaction policies, and minimizing risk during upgrades. For basic signing, start with the [Quickstart](/solutions/company-wallets/quickstart).
+
+## Powered by Turnkey
+
+Teams managing high-value contracts use Turnkey for policy-enforced signing at every stage:
+
+- [**Polymarket**](/solutions/cookbooks/polymarket-builders) transitioned to Turnkey for secure contract interactions at scale, including Safe deployment and gasless trading infrastructure.
+- [**Brale**](/solutions/cookbooks/brale) uses Turnkey's policy engine to constrain stablecoin minting and transfer operations to an allowlist of approved contracts.
+
+Turnkey also fits **existing** contract deployments. You don't need to redeploy to start managing signing through Turnkey.
+
+## Key implementation decisions
+
+| Decision | What to consider |
+| :--- | :--- |
+| Role isolation | Separate wallets for deployer, operator, and upgrade owner so each role has its own keys and scoped policies |
+| Deployment permissions | Policy scoping the deployer to a specific wallet and network |
+| Function-level controls | Policies targeting specific contract addresses and function signatures, or [upload the ABI](/features/policies/smart-contract-interfaces) for full parsing |
+| Value thresholds | Automated approval for routine operations (small mints), multi-party consensus for large ones |
+| Upgrade controls | Grant upgrade permissions only when needed via temporary policies, then revoke immediately after |
+
+## Example: stablecoins and RWAs
+
+Stablecoins and tokenized Real-World Assets often secure billions of dollars in value. These contracts typically involve minting, burning, pausing, and upgrades, each requiring different levels of authorization.
+
+| Need | How Turnkey solves it |
+| :--- | :--- |
+| Minting must be constrained to approved limits | Policies can bound mint amounts and require multi-party approval above a threshold via [smart contract interfaces](/features/policies/smart-contract-interfaces) |
+| Only authorized addresses can receive new supply | Policies target specific contract addresses and function arguments, restricting who the `mint` recipient can be |
+| Must support emergency pause | A dedicated pause operator wallet with a scoped policy for the `pause` function, separate from day-to-day minting |
+| Upgrades must not introduce unreviewed logic | Temporary upgrade policies with multi-party consensus, revoked immediately after execution |
+| Full audit trail of every operation | Every signing action is an activity in Turnkey with a complete audit log of who approved what and when |
+
+
+
+### Implementation steps
+
+
+
diff --git a/cookbook/0x.mdx b/solutions/cookbooks/0x.mdx
similarity index 98%
rename from cookbook/0x.mdx
rename to solutions/cookbooks/0x.mdx
index 74d7d81b..3f312034 100644
--- a/cookbook/0x.mdx
+++ b/solutions/cookbooks/0x.mdx
@@ -13,7 +13,7 @@ We'll demonstrate this using the [`with-0x`](https://github.com/tkhq/sdk/tree/ma
## Getting started
-Before you begin, make sure you’ve followed the [Turnkey Quickstart guide](/getting-started/quickstart).
+Before you begin, make sure you’ve followed the [Turnkey Quickstart guide](/get-started/quickstart).
You should have:
- A Turnkey **organization** and **Auth Proxy Config ID**
@@ -218,7 +218,7 @@ if (currentAllowance < parseUnits(fromAmount, 6)) {
## Summary
-✅ You’ve now learned how to:
+You’ve now learned how to:
- Authenticate with Turnkey via @turnkey/react-wallet-kit
diff --git a/cookbook/aave.mdx b/solutions/cookbooks/aave.mdx
similarity index 99%
rename from cookbook/aave.mdx
rename to solutions/cookbooks/aave.mdx
index f6b5ea5f..fd51d9ae 100644
--- a/cookbook/aave.mdx
+++ b/solutions/cookbooks/aave.mdx
@@ -13,7 +13,7 @@ A working example can be found [here](https://github.com/tkhq/sdk/tree/main/exam
## Getting started
-The first step is to set up your Turnkey organization and account. By following the [Quickstart guide](/getting-started/quickstart), you should have:
+The first step is to set up your Turnkey organization and account. By following the [Quickstart guide](/get-started/quickstart), you should have:
- A root user with a public/private API key pair within the Turnkey parent organization
- An organization ID
diff --git a/cookbook/base-builder-codes.mdx b/solutions/cookbooks/base-builder-codes.mdx
similarity index 96%
rename from cookbook/base-builder-codes.mdx
rename to solutions/cookbooks/base-builder-codes.mdx
index ced71d33..7fde64b9 100644
--- a/cookbook/base-builder-codes.mdx
+++ b/solutions/cookbooks/base-builder-codes.mdx
@@ -1,6 +1,6 @@
---
title: "Builder codes with Turnkey on Base"
-sidebarTitle: "Base Builders"
+sidebarTitle: "Base builders"
---
## Overview
@@ -11,7 +11,7 @@ By appending an encoded Builder Code to transaction data, you can track usage an
## Getting started
-The first step is to set up your Turnkey organization and account. By following the [Quickstart guide](/getting-started/quickstart), you should have:
+The first step is to set up your Turnkey organization and account. By following the [Quickstart guide](/get-started/quickstart), you should have:
- A root user with a public/private API key pair within the Turnkey parent organization
- An organization ID
@@ -145,4 +145,4 @@ To confirm your Builder Code is being appended correctly:
- [Base Builder Codes documentation](https://docs.base.org/base-chain/builder-codes/builder-codes)
- [ERC-8021 specification](https://www.erc8021.com/)
- [Turnkey viem integration](/sdks/web3/viem)
-- [Turnkey policy engine](/concepts/policies/overview)
+- [Turnkey policy engine](/features/policies/overview)
diff --git a/cookbook/brale.mdx b/solutions/cookbooks/brale.mdx
similarity index 100%
rename from cookbook/brale.mdx
rename to solutions/cookbooks/brale.mdx
diff --git a/cookbook/breeze.mdx b/solutions/cookbooks/breeze.mdx
similarity index 98%
rename from cookbook/breeze.mdx
rename to solutions/cookbooks/breeze.mdx
index 3cb533a5..e50e18c2 100644
--- a/cookbook/breeze.mdx
+++ b/solutions/cookbooks/breeze.mdx
@@ -13,7 +13,7 @@ We'll demonstrate this using the [`with-breeze`](https://github.com/tkhq/sdk/tre
## Getting started
-Before you begin, make sure you’ve followed the [Turnkey Quickstart guide](/getting-started/quickstart).
+Before you begin, make sure you’ve followed the [Turnkey Quickstart guide](/get-started/quickstart).
You should have
- A Turnkey **organization** and **Auth Proxy Config ID**
@@ -224,7 +224,7 @@ async function handleCheckData(userId: string) {
## Summary
-✅ You’ve now learned how to:
+You’ve now learned how to:
- Authenticate with Turnkey via @turnkey/react-wallet-kit
diff --git a/cookbook/jupiter.mdx b/solutions/cookbooks/jupiter.mdx
similarity index 98%
rename from cookbook/jupiter.mdx
rename to solutions/cookbooks/jupiter.mdx
index b21b538e..04b219e1 100644
--- a/cookbook/jupiter.mdx
+++ b/solutions/cookbooks/jupiter.mdx
@@ -14,7 +14,7 @@ You’ll learn how to authenticate with Turnkey, load a wallet, and use it to cr
## Getting started
-Before you begin, make sure you’ve followed the [Turnkey Quickstart guide](/getting-started/quickstart).
+Before you begin, make sure you’ve followed the [Turnkey Quickstart guide](/get-started/quickstart).
You should have:
- A Turnkey **organization** and **Auth Proxy Config ID**
@@ -266,7 +266,7 @@ console.log("User balances:", JSON.stringify(balancesResponse, null, 2));
## Summary
-✅ You’ve now learned how to:
+You’ve now learned how to:
- Authenticate a user with Turnkey
diff --git a/solutions/cookbooks/landing.mdx b/solutions/cookbooks/landing.mdx
new file mode 100644
index 00000000..eea0eebf
--- /dev/null
+++ b/solutions/cookbooks/landing.mdx
@@ -0,0 +1,83 @@
+---
+title: "Cookbooks"
+description: "Step-by-step guides for integrating Turnkey with protocols, platforms, and services."
+sidebarTitle: "Overview"
+slug: "cookbook/landing"
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx';
+
+
+
diff --git a/cookbook/lifi.mdx b/solutions/cookbooks/lifi.mdx
similarity index 99%
rename from cookbook/lifi.mdx
rename to solutions/cookbooks/lifi.mdx
index 725ea08b..417ef26e 100644
--- a/cookbook/lifi.mdx
+++ b/solutions/cookbooks/lifi.mdx
@@ -13,7 +13,7 @@ We'll demonstrate this using the [`with-lifi`](https://github.com/tkhq/sdk/tree/
## Getting started
-Before you begin, make sure you’ve followed the [Turnkey Quickstart guide](/getting-started/quickstart).
+Before you begin, make sure you’ve followed the [Turnkey Quickstart guide](/get-started/quickstart).
You should have:
- A Turnkey **organization** and **Auth Proxy Config ID**
@@ -248,7 +248,7 @@ async function getStatus() {
## Summary
-✅ You’ve now learned how to:
+You’ve now learned how to:
- Authenticate with Turnkey via @turnkey/react-wallet-kit
diff --git a/cookbook/morpho.mdx b/solutions/cookbooks/morpho.mdx
similarity index 99%
rename from cookbook/morpho.mdx
rename to solutions/cookbooks/morpho.mdx
index be0ae82b..46f79449 100644
--- a/cookbook/morpho.mdx
+++ b/solutions/cookbooks/morpho.mdx
@@ -13,7 +13,7 @@ The working example can be found [here](https://github.com/tkhq/sdk/tree/main/ex
## Getting started
-The first step is to set up your Turnkey organization and account. By following the [Quickstart guide](/getting-started/quickstart), you should have:
+The first step is to set up your Turnkey organization and account. By following the [Quickstart guide](/get-started/quickstart), you should have:
- A root user with a public/private API key pair within the Turnkey parent organization
- An organization ID
diff --git a/cookbook/polymarket-builders.mdx b/solutions/cookbooks/polymarket-builders.mdx
similarity index 99%
rename from cookbook/polymarket-builders.mdx
rename to solutions/cookbooks/polymarket-builders.mdx
index cf4015d8..c2698ce6 100644
--- a/cookbook/polymarket-builders.mdx
+++ b/solutions/cookbooks/polymarket-builders.mdx
@@ -1,6 +1,6 @@
---
title: 'Polymarket builders with Turnkey'
-sidebarTitle: "Polymarket Builders"
+sidebarTitle: "Polymarket builders"
---
## Overview
diff --git a/cookbook/relay.mdx b/solutions/cookbooks/relay.mdx
similarity index 97%
rename from cookbook/relay.mdx
rename to solutions/cookbooks/relay.mdx
index 41f6cd06..a1154ec9 100644
--- a/cookbook/relay.mdx
+++ b/solutions/cookbooks/relay.mdx
@@ -161,7 +161,7 @@ For a real-time stream instead of polling, you can use [Relay’s WebSocket API]
## Handling EIP-191 and EIP-712 signatures
-Some Relay steps (particularly for swaps) require off-chain signatures before the deposit transaction. Handle both signature kinds with the Turnkey-backed viem wallet client:
+Some Relay steps (particularly for swaps) require offchain signatures before the deposit transaction. Handle both signature kinds with the Turnkey-backed viem wallet client:
```tsx
"use client";
@@ -193,7 +193,7 @@ async function signItem(walletClient: WalletClient, item: StepItem): Promise
+
diff --git a/solutions/embedded-wallets/embedded-consumer-wallet.mdx b/solutions/embedded-wallets/embedded-consumer-wallet.mdx
new file mode 100644
index 00000000..e9c1554b
--- /dev/null
+++ b/solutions/embedded-wallets/embedded-consumer-wallet.mdx
@@ -0,0 +1,64 @@
+---
+title: "Embedded Consumer Wallet"
+description: "Give every user of your application their own wallet, provisioned automatically at signup."
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx';
+
+With Turnkey, you can provision a dedicated wallet for every user as part of your application's signup flow, at any scale. Users authenticate with familiar methods like passkeys, email, or social login. They never manage keys or install extensions.
+
+## Powered by Turnkey
+
+- [**Moonshot**](https://www.turnkey.com/customers/how-moonshot-powers-millions-of-self-custodial-wallets-using-turnkey) -- millions of self-custodial wallets powering one of crypto's fastest-growing consumer apps
+- [**Infinex**](https://www.turnkey.com/customers/making-onchain-ux-seamless-with-infinex-and-turnkey) -- seamless onchain UX for a unified DeFi experience
+- [**Axiom**](https://www.turnkey.com/customers/axiom-global-defi-trading-platform) -- global DeFi trading platform with embedded wallet infrastructure
+
+## Key implementation decisions
+
+Turnkey enables developers to tailor non-custodial, embedded user wallets across dimensions such as
+custody model, authentication, and more. See the key implementation decisions below to curate the
+exact user experience you need.
+
+| Decision | Explanation | Learn more |
+| :------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Custody model** | Choose who can authorize the enclave to sign: the user only (non-custodial), your application (custodial), or both with scoped permissions (hybrid). | [Custody models](/solutions/embedded-wallets/overview#custody-models) |
+| **Authentication methods** | Choose user auth methods: Passkeys, OAuth/email, or SMS. You can use the [Auth Proxy](/features/authentication/auth-proxy) for backend-signed OTP/OAuth/signup without your own backend, or wire auth to your app. | [Authentication Overview](/features/authentication/overview), [Auth Proxy](/features/authentication/auth-proxy) |
+| **Policies and guardrails** | Set guardrails for what your end users can do, such as spending limits, allowed destinations, or multi-party approval. Optionally let users configure their own guardrails within your app. | [Policies](/features/policies/overview), [Delegated Access](/features/policies/delegated-access/overview) |
+| **Session management** | Allow a user to take multiple, contiguous actions in a defined period of time. Actions include: Read-write or read-only. | [Sessions](/features/authentication/sessions) |
+| **Wallet architecture** | Choose between key-based (HD) or smart contract wallets for your users. Turnkey supports both. | [Wallets Concept](/features/wallets), [Transaction Management](/features/transaction-management) |
+| **Gas sponsorship** | Integrate a gasless UX via sponsored transactions to cover who pays gas and how transactions are broadcast. | [Transaction Management](/features/transaction-management), [Sending sponsored transactions](/features/transaction-management/sending-sponsored-transactions) |
+| **Key portability** | Determine whether users can import or export keys. | [Import wallets](/features/wallets/import-wallets), [Export wallets](/features/wallets/export-wallets) |
+| **Recovery flows** | Define how users regain access if they lose their authenticator. Options include email recovery and backup passkeys. | [Email recovery](/features/authentication/email) |
+| **Agent-delegated signing** | Let end users grant scoped signing authority to AI agents or automated systems from their own wallet. The user retains root control and can revoke access at any time. | [End-User Delegated Agent Signing](/features/policies/delegated-access/agentic-wallets) |
+
+## Example: Neobank-style embedded consumer wallet
+
+Typical requirements and how Turnkey addresses them:
+
+| Requirement | Turnkey capability |
+| :-------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Seamless onboarding | Passkey registration and automated wallet provisioning. See [Quickstart](/solutions/embedded-wallets/quickstart) or [Integration Guide](/solutions/embedded-wallets/integration-guide/overview) |
+| User custody without key exposure | Keys remain in [secure enclaves](/security/secure-enclaves); only signatures are returned. See [Security](/security/our-approach) |
+| Gasless UX | [Sponsored transactions](/features/transaction-management) and [sending sponsored transactions](/features/transaction-management/sending-sponsored-transactions) |
+| Email-based auth and recovery | [Sub-organization recovery](/features/authentication/email) |
+| Send without wallet setup | [Claim links](/features/wallets/claim-links#claim-links): send via URL; recipient claims with email |
+| Backend automation | [Delegated access](/features/policies/delegated-access/overview) and scoped signing policies |
+| Multichain support | Chain-agnostic derivation and signing. See [Networks](/features/networks/overview) and [Wallets Concept](/features/wallets) |
+| Fast integration | Use the [Embedded Wallet Kit](/solutions/embedded-wallets/integration-guide/react/index) for built-in auth and wallet UI components. See [Quickstart](/solutions/embedded-wallets/quickstart) |
+
+## Next steps
+
+
+
diff --git a/solutions/embedded-wallets/embedded-waas.mdx b/solutions/embedded-wallets/embedded-waas.mdx
new file mode 100644
index 00000000..0d650751
--- /dev/null
+++ b/solutions/embedded-wallets/embedded-waas.mdx
@@ -0,0 +1,176 @@
+---
+title: "Embedded Wallet-as-a-Service"
+sidebarTitle: "Wallet-as-a-Service"
+description: "Distribute embedded wallets through your developer platform with co-signing authority, billing gates, and compliance controls."
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx'
+
+With Turnkey, you can build a platform that distributes embedded wallets to your own customers. Your platform abstracts Turnkey behind your own SDK, APIs, or UI components. A 2-of-2 root quorum model gives your platform co-signing authority over every transaction, enabling billing gates, compliance checks, and risk controls at the infrastructure layer, while end users remain non-custodial.
+
+## Powered by Turnkey
+
+- [**DIMO**](https://www.turnkey.com/customers/how-dimo-is-bringing-transportation-solutions-onchain-with-turnkey) -- decentralized transportation network with 165,000+ connected vehicles. 90% reduction in onboarding time, 30% increase in completion rates. Built their own [transactions SDK](https://github.com/DIMO-Network/transactions) on Turnkey's infrastructure
+
+## What makes Wallet-as-a-Service different
+
+With [consumer wallets](/solutions/embedded-wallets/embedded-consumer-wallet) and [business wallets](/solutions/embedded-wallets/embedded-business-wallets), your application integrates Turnkey directly and manages wallets for end users. With Wallet-as-a-Service, your platform is an intermediary layer: you build wallet infrastructure on top of Turnkey, and your customers integrate with your SDK rather than Turnkey directly.
+
+The defining pattern is the **2-of-2 root quorum**. Both the end user and your platform must approve every fund-moving transaction. The end user authenticates via passkey (or equivalent), then your platform evaluates its own rules (billing status, compliance, risk) before co-signing. If either party withholds approval, the transaction does not execute.
+
+No transaction executes without the end user's authentication. End users remain non-custodial because they can always [export their keys](/features/wallets/export-wallets) independently, without platform approval.
+
+### When to use Wallet-as-a-Service
+
+| Scenario | Why Wallet-as-a-Service fits |
+| :-------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------- |
+| Your customers embed wallets through your SDK, not Turnkey's | You own the developer experience end-to-end. Downstream integrators never interact with Turnkey directly. |
+| You need platform-level co-signing on every transaction | 2-of-2 root quorum lets your platform enforce billing gates, compliance checks, or risk controls before any fund-moving transaction. |
+| You want to white-label wallet infrastructure | Fork or wrap the Embedded Wallet Kit with your branding and expose your own APIs. Turnkey is invisible to your customers. |
+
+## Architecture
+
+Each end user maps to a [Turnkey sub-organization](/features/sub-organizations). The sub-org contains the user's wallets, credentials, policies, and activity logs, fully isolated from other users and from your platform's management layer.
+
+
+
+
+
+### Transaction authorization flow
+
+1. End user initiates a transaction from your embedded wallet UI
+2. End user approves via their authenticator (e.g. passkey). Turnkey records the activity as partially approved
+3. Your platform evaluates on its backend: billing status, risk/compliance rules, and any other checks
+4. Your platform approves via API key and the transaction executes
+5. If the platform withholds approval, the transaction does not execute
+
+
+
+
+
+See [Activities and approvals](/get-started/about-turnkey#activities) and [Root quorum](/features/users/root-quorum).
+
+## Implementation
+
+### Step 1: Define the tenant model
+
+Map each end user to a [sub-organization](/features/sub-organizations). One sub-org per end user.
+
+- **Isolated tenants:** Each sub-org is a self-contained data boundary with wallets, policies, authenticators, and activity logs fully isolated from one another.
+- **Scoped parent org permissions:** Your parent organization has read-only access to sub-orgs and can initiate auth and recovery flows, but cannot sign transactions or modify policies within them.
+- **External mapping:** Track the relationship between your platform's user IDs and their corresponding Turnkey sub-org IDs in your own database.
+
+See [Sub-organizations](/features/sub-organizations) and [Root quorum](/features/users/root-quorum).
+
+### Step 2: Design the sub-organization control model
+
+Define what lives inside each sub-org and how control is shared between your platform and the end user.
+
+- **End user (root):** Authenticated via passkey or equivalent user-controlled authenticator.
+- **Platform provider (root):** Authenticated via API key. Used to approve or block transactions based on your service rules.
+- **Delegated access (optional):** For automation or backend-initiated workflows, add a scoped non-root API key via [Delegated Access](/features/policies/delegated-access/overview). This must be tightly policy-scoped and should never have broad signing authority or bypass user consent.
+
+See [Delegated Access](/features/policies/delegated-access/overview) and [Policies](/features/policies/overview).
+
+### Step 3: Create sub-org with wallet and export policy
+
+Specify what gets created in every sub-org by default: wallet structure, supported chains/accounts, and baseline policies.
+
+For the 2-of-2 quorum model, establish the threshold last so your platform can configure policies (including export) with only your platform's approval. Once the 2-of-2 quorum is established, the end user can trigger exports via the export policy without needing your platform's co-signature. This keeps the co-managed model non-custodial: end users can always export their keys and access their funds directly, independent of your platform.
+
+| Step | Action | Quorum State |
+| ---- | --------------------------------------------- | ------------ |
+| 3a | Create sub-org with both root users + wallet | 1-of-2 |
+| 3b | Create export policy for end user | 1-of-2 |
+| 3c | Update threshold to 2 | **2-of-2** |
+
+**3a. Create sub-org with both root users at 1-of-2 threshold**
+
+```javascript
+const subOrg = await turnkeyClient.createSubOrganization({
+ parameters: {
+ subOrganizationName: `User Wallet - ${userId}`,
+ rootUsers: [
+ { userName: "Platform", apiKeys: [{ publicKey: PROVIDER_KEY }] },
+ {
+ userName: "End User",
+ authenticators: [
+ {
+ /* passkey */
+ },
+ ],
+ },
+ ],
+ rootQuorumThreshold: 1,
+ wallet: {
+ walletName: "Primary Wallet",
+ accounts: [
+ {
+ /* eth account */
+ },
+ ],
+ },
+ },
+});
+```
+
+**3b. Create export policy (user escape hatch)**
+
+```javascript
+await turnkeyClient.createPolicy({
+ organizationId: subOrgId,
+ parameters: {
+ policyName: "Allow User Wallet Export",
+ effect: "EFFECT_ALLOW",
+ consensus: `approvers.any(user, user.id == '${endUserId}')`,
+ condition: `activity.type == 'ACTIVITY_TYPE_EXPORT_WALLET'
+ && wallet.id == '${walletId}'`,
+ },
+});
+```
+
+**3c. Raise threshold to 2-of-2**
+
+```javascript
+await turnkeyClient.updateRootQuorum({
+ organizationId: subOrgId,
+ parameters: {
+ threshold: 2,
+ userIds: [providerUserId, endUserId],
+ },
+});
+```
+
+See [Export wallets](/features/wallets/export-wallets) and [Policy examples](/features/policies/examples/access-control).
+
+### Step 4: Build your integration surface
+
+Create the SDK, APIs, or UI components that downstream developers will integrate with. Abstract Turnkey and expose only your platform's intended wallet, auth, and signing flows.
+
+- **Embedded Wallet Kit (EWK):** Fork or wrap [EWK](/solutions/embedded-wallets/integration-guide/react/index) components (authentication, wallet UI, approval prompts) with your branding. Surface "pending platform approval" states in the transaction flow.
+- **Backend service:** Handle platform root approvals (via API key), billing and risk evaluation, and activity monitoring through your backend.
+- **SDK abstraction layer:** Wrap Turnkey's SDK calls behind your own interface for full control over the developer experience.
+
+See [Embedded Wallet Kit](/solutions/embedded-wallets/integration-guide/react/index) and [SDK Reference](/sdks/introduction).
+
+### Step 5: Wire the wallet into your platform flow
+
+Integrate the wallet into your onboarding and runtime flows so every downstream integration inherits a working embedded wallet.
+
+- **Onboarding:** Handle Turnkey org setup, auth configuration, and the staged sub-org creation flow as part of user registration. The end user should experience passkey registration as a natural part of sign-up.
+- **Client initialization:** Initialize the Turnkey client with the user's sub-org context on each session. Use [sessions](/features/authentication/sessions) for batched signing workflows to reduce authentication friction.
+- **Transaction flow:** Surface the approval prompt via EWK components, submit the user's approval to Turnkey, run your backend checks, then co-sign or withhold.
+- **Recovery:** Expose the export flow in your settings UI so users can self-serve wallet recovery. Turnkey's enclave encrypts the mnemonic to a user-generated target key via HPKE. Neither Turnkey nor your platform can view the exported material.
+
+## Next steps
+
+
+
diff --git a/sdks/flutter/advanced-api-requests.mdx b/solutions/embedded-wallets/integration-guide/flutter/advanced-api-requests.mdx
similarity index 92%
rename from sdks/flutter/advanced-api-requests.mdx
rename to solutions/embedded-wallets/integration-guide/flutter/advanced-api-requests.mdx
index cef999b2..1edd40cd 100644
--- a/sdks/flutter/advanced-api-requests.mdx
+++ b/solutions/embedded-wallets/integration-guide/flutter/advanced-api-requests.mdx
@@ -15,7 +15,7 @@ However, you can also make advanced API requests directly to Turnkey's endpoints
To make advanced API requests, use the `client` retrieved from the `TurnkeyProvider`.
This client is tied to the active session, so stamping, authentication, and organization context are automatically handled for you.
-You can see the [API Reference](/api-reference/overview) for a complete list of available API endpoints and their parameters. All of these can be accessed through the `client`.
+You can see the [API Reference](/api-reference/overview/intro) for a complete list of available API endpoints and their parameters. All of these can be accessed through the `client`.
Here's how you can use the `client` to make a `signRawPayload` request to Turnkey:
@@ -108,5 +108,5 @@ final passkeyClient = await tk.createPasskeyClient(
);
```
-To learn more about using passkeys in your Flutter app, check out the [Passkey Authentication](/sdks/flutter/authentication/passkey) guide.
+To learn more about using passkeys in your Flutter app, check out the [Passkey Authentication](/solutions/embedded-wallets/integration-guide/flutter/authentication/passkey) guide.
diff --git a/sdks/flutter/authentication/email-sms.mdx b/solutions/embedded-wallets/integration-guide/flutter/authentication/email-sms.mdx
similarity index 100%
rename from sdks/flutter/authentication/email-sms.mdx
rename to solutions/embedded-wallets/integration-guide/flutter/authentication/email-sms.mdx
diff --git a/sdks/flutter/authentication/overview.mdx b/solutions/embedded-wallets/integration-guide/flutter/authentication/overview.mdx
similarity index 84%
rename from sdks/flutter/authentication/overview.mdx
rename to solutions/embedded-wallets/integration-guide/flutter/authentication/overview.mdx
index 15989f21..3c37298c 100644
--- a/sdks/flutter/authentication/overview.mdx
+++ b/solutions/embedded-wallets/integration-guide/flutter/authentication/overview.mdx
@@ -4,6 +4,8 @@ description: "Learn how to set up, log in, or sign up easily in your Flutter app
sidebarTitle: "Overview"
---
+import { FeatureCard } from '/snippets/feature-card.mdx'
+
Turnkey's Flutter SDK makes authentication simple. You can call specific login and signup functions (email/SMS OTP, passkeys, or social logins) to build your own UI and auth flow.
## Authentication state
@@ -132,36 +134,12 @@ class DashboardScreenState extends State
+
\ No newline at end of file
diff --git a/sdks/flutter/authentication/passkey.mdx b/solutions/embedded-wallets/integration-guide/flutter/authentication/passkey.mdx
similarity index 100%
rename from sdks/flutter/authentication/passkey.mdx
rename to solutions/embedded-wallets/integration-guide/flutter/authentication/passkey.mdx
diff --git a/sdks/flutter/authentication/social-logins.mdx b/solutions/embedded-wallets/integration-guide/flutter/authentication/social-logins.mdx
similarity index 98%
rename from sdks/flutter/authentication/social-logins.mdx
rename to solutions/embedded-wallets/integration-guide/flutter/authentication/social-logins.mdx
index 77fa6ebd..fe3fc6f1 100644
--- a/sdks/flutter/authentication/social-logins.mdx
+++ b/solutions/embedded-wallets/integration-guide/flutter/authentication/social-logins.mdx
@@ -11,7 +11,7 @@ Using OAuth requires configuration in the Turnkey Dashboard and in your app.
### Enabling OAuth
-Navigate to the **Wallet Kit** section in the [Turnkey Dashboard](https://app.turnkey.com/dashboard/walletKit) and enable **OAuth**. If you have not enabled the Auth Proxy, enable it first. See [Getting Started](/sdks/flutter/getting-started) for details.
+Navigate to the **Wallet Kit** section in the [Turnkey Dashboard](https://app.turnkey.com/dashboard/walletKit) and enable **OAuth**. If you have not enabled the Auth Proxy, enable it first. See [Getting Started](/solutions/embedded-wallets/integration-guide/flutter/getting-started) for details.
diff --git a/sdks/flutter/getting-started.mdx b/solutions/embedded-wallets/integration-guide/flutter/getting-started.mdx
similarity index 98%
rename from sdks/flutter/getting-started.mdx
rename to solutions/embedded-wallets/integration-guide/flutter/getting-started.mdx
index 6013c18c..b036b12b 100644
--- a/sdks/flutter/getting-started.mdx
+++ b/solutions/embedded-wallets/integration-guide/flutter/getting-started.mdx
@@ -6,7 +6,7 @@ sidebarTitle: "Getting started"
## Turnkey organization setup
-To start, you must create a Turnkey organization via the [Turnkey dashboard](https://app.turnkey.com). The steps to do so are described in the [Account Setup](/getting-started/quickstart) section.
+To start, you must create a Turnkey organization via the [Turnkey dashboard](https://app.turnkey.com). The steps to do so are described in the [Account Setup](/get-started/quickstart) section.
For this setup, we will be using Turnkey's Auth Proxy to handle authentication. We can enable and configure this through the Turnkey dashboard.
diff --git a/solutions/embedded-wallets/integration-guide/flutter/index.mdx b/solutions/embedded-wallets/integration-guide/flutter/index.mdx
new file mode 100644
index 00000000..f11b53c8
--- /dev/null
+++ b/solutions/embedded-wallets/integration-guide/flutter/index.mdx
@@ -0,0 +1,17 @@
+---
+title: "Overview"
+description: "Turnkey's Flutter SDK [`(turnkey_sdk_flutter)`](https://pub.dev/packages/turnkey_sdk_flutter) is the easiest way to integrate Turnkey’s Embedded Wallets into your Flutter applications. It supports both backendless setups via Turnkey’s managed [Auth Proxy](https://docs.turnkey.com/reference/auth-proxy) and traditional backend-based architectures. It provides a set of functions and utilities to interact with Turnkey's APIs, a powerful session management system, built-in stampers, and a raw HTTP client for advanced use cases."
+sidebarTitle: "Overview"
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx'
+
+Find `turnkey_sdk_flutter` on [pub.dev](https://pub.dev/packages/turnkey_sdk_flutter) or view the source code on [GitHub](https://github.com/tkhq/dart-sdk)! For a working reference implementation covering auth, wallet creation, export, and signing, see the [flutter-demo-app](https://github.com/tkhq/dart-sdk/tree/main/examples/flutter-demo-app) example app.
+
+
+
\ No newline at end of file
diff --git a/sdks/flutter/signing.mdx b/solutions/embedded-wallets/integration-guide/flutter/signing.mdx
similarity index 100%
rename from sdks/flutter/signing.mdx
rename to solutions/embedded-wallets/integration-guide/flutter/signing.mdx
diff --git a/sdks/flutter/sub-organization-customization.mdx b/solutions/embedded-wallets/integration-guide/flutter/sub-organization-customization.mdx
similarity index 94%
rename from sdks/flutter/sub-organization-customization.mdx
rename to solutions/embedded-wallets/integration-guide/flutter/sub-organization-customization.mdx
index 83ee7401..b5da0e38 100644
--- a/sdks/flutter/sub-organization-customization.mdx
+++ b/solutions/embedded-wallets/integration-guide/flutter/sub-organization-customization.mdx
@@ -96,4 +96,4 @@ For a full list of parameters available, inspect the `CreateSubOrgParams` class
## Next steps
-Now that you can customize sub-org creation in Flutter, check out the [Using Embedded Wallets](/sdks/flutter/using-embedded-wallets) guide next to learn how to create and manage wallets within your app!
+Now that you can customize sub-org creation in Flutter, check out the [Using Embedded Wallets](/solutions/embedded-wallets/integration-guide/flutter/using-embedded-wallets) guide next to learn how to create and manage wallets within your app!
diff --git a/sdks/flutter/using-embedded-wallets.mdx b/solutions/embedded-wallets/integration-guide/flutter/using-embedded-wallets.mdx
similarity index 96%
rename from sdks/flutter/using-embedded-wallets.mdx
rename to solutions/embedded-wallets/integration-guide/flutter/using-embedded-wallets.mdx
index b9c31b76..703f227e 100644
--- a/sdks/flutter/using-embedded-wallets.mdx
+++ b/solutions/embedded-wallets/integration-guide/flutter/using-embedded-wallets.mdx
@@ -8,7 +8,7 @@ sidebarTitle: "Using embedded wallets"
Turnkey's Flutter SDK provides a straightforward way to create and manage embedded wallets in your Flutter application. You can create wallets, derive accounts, import wallets, and keep local UI state in sync with provider data.
-Before starting, review the concepts of **[Wallets](/concepts/wallets)** and **[Wallet Accounts](/concepts/wallets#accounts)**.
+Before starting, review the concepts of **[Wallets](/features/wallets)** and **[Wallet Accounts](/features/wallets#accounts)**.
## Creating an embedded wallet
@@ -250,7 +250,7 @@ class ExportWalletButton extends StatelessWidget {
## Next steps
-Continue to **[Signing](/sdks/flutter/signing)** to learn how to sign messages and transactions with your embedded wallets.
+Continue to **[Signing](/solutions/embedded-wallets/integration-guide/flutter/signing)** to learn how to sign messages and transactions with your embedded wallets.
diff --git a/sdks/kotlin/advanced-api-requests.mdx b/solutions/embedded-wallets/integration-guide/kotlin/advanced-api-requests.mdx
similarity index 96%
rename from sdks/kotlin/advanced-api-requests.mdx
rename to solutions/embedded-wallets/integration-guide/kotlin/advanced-api-requests.mdx
index 941654ee..21bf545d 100644
--- a/sdks/kotlin/advanced-api-requests.mdx
+++ b/solutions/embedded-wallets/integration-guide/kotlin/advanced-api-requests.mdx
@@ -13,7 +13,7 @@ However, you can also make advanced API requests directly to Turnkey's endpoints
To make advanced API requests, use the `client` from the `TurnkeyContext`.
-You can see the [API Reference](/api-reference/overview) for a complete list of available API endpoints and their parameters. All of these can be accessed through the `client`.
+You can see the [API Reference](/api-reference/overview/intro) for a complete list of available API endpoints and their parameters. All of these can be accessed through the `client`.
Here's how you can use the `client` to make a `signRawPayload` request to Turnkey:
diff --git a/sdks/kotlin/authentication/email-sms.mdx b/solutions/embedded-wallets/integration-guide/kotlin/authentication/email-sms.mdx
similarity index 100%
rename from sdks/kotlin/authentication/email-sms.mdx
rename to solutions/embedded-wallets/integration-guide/kotlin/authentication/email-sms.mdx
diff --git a/solutions/embedded-wallets/integration-guide/kotlin/authentication/overview.mdx b/solutions/embedded-wallets/integration-guide/kotlin/authentication/overview.mdx
new file mode 100644
index 00000000..64ca0f8d
--- /dev/null
+++ b/solutions/embedded-wallets/integration-guide/kotlin/authentication/overview.mdx
@@ -0,0 +1,32 @@
+---
+title: "Overview"
+description: "Learn how to set up, log in, or sign up easily in your Android app using the Turnkey Kotlin SDK."
+sidebarTitle: "Overview"
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx'
+
+The Kotlin SDK makes authentication simple.
+You can call specific login and signup functions to create your own UI components and authentication flow.
+
+## Authentication state
+
+To check if a user is authenticated, you can use the `authState` variable from the `TurnkeyContext`.
+
+```kotlin
+val authState: AuthState = TurnkeyContext.authState.value
+```
+
+## Customize sub-organization creation
+
+Need to configure default user names, passkey names, wallet creations or anything sub-org related?
+You can learn more about customizing the sub-orgs you create in the [Sub-Organization Customization](/solutions/embedded-wallets/integration-guide/kotlin/sub-organization-customization) section.
+
+Follow the guides below to learn how to set up email and SMS authentication, passkey authentication, and social logins in your Android app.
+
+
+
\ No newline at end of file
diff --git a/sdks/kotlin/authentication/passkey.mdx b/solutions/embedded-wallets/integration-guide/kotlin/authentication/passkey.mdx
similarity index 95%
rename from sdks/kotlin/authentication/passkey.mdx
rename to solutions/embedded-wallets/integration-guide/kotlin/authentication/passkey.mdx
index 668af116..8e7cb7ca 100644
--- a/sdks/kotlin/authentication/passkey.mdx
+++ b/solutions/embedded-wallets/integration-guide/kotlin/authentication/passkey.mdx
@@ -12,7 +12,7 @@ You'll add the necessary platform configuration, set up the provider with a prop
## Passkey setup
To enable passkeys, you must configure your app's relying party ID (`rpId`) correctly.
-For Android, you must configure a Digital Asset Links by setting up an `assetlinks.json` file. Refer to [our relying party setup guide](/sdks/kotlin/authentication/rp-id-setup) and [Google's Documentation](https://developer.android.com/training/app-links/verify-android-applinks).
+For Android, you must configure a Digital Asset Links by setting up an `assetlinks.json` file. Refer to [our relying party setup guide](/solutions/embedded-wallets/integration-guide/kotlin/authentication/rp-id-setup) and [Google's Documentation](https://developer.android.com/training/app-links/verify-android-applinks).
### 1. Ensure `rpId` is set correctly in your Turnkey SDK initialization
diff --git a/sdks/kotlin/authentication/rp-id-setup.mdx b/solutions/embedded-wallets/integration-guide/kotlin/authentication/rp-id-setup.mdx
similarity index 100%
rename from sdks/kotlin/authentication/rp-id-setup.mdx
rename to solutions/embedded-wallets/integration-guide/kotlin/authentication/rp-id-setup.mdx
diff --git a/sdks/kotlin/authentication/social-logins.mdx b/solutions/embedded-wallets/integration-guide/kotlin/authentication/social-logins.mdx
similarity index 96%
rename from sdks/kotlin/authentication/social-logins.mdx
rename to solutions/embedded-wallets/integration-guide/kotlin/authentication/social-logins.mdx
index d0b6dcb6..b451a408 100644
--- a/sdks/kotlin/authentication/social-logins.mdx
+++ b/solutions/embedded-wallets/integration-guide/kotlin/authentication/social-logins.mdx
@@ -11,7 +11,7 @@ Using OAuth requires a bit of configuration in the Turnkey Dashboard and your ap
### Enabling OAuth
Navigate to the **Wallet Kit** section in the [Turnkey Dashboard](https://app.turnkey.com/dashboard/walletKit) and enable the
-**OAuth**. Note if you have not enabled the Auth Proxy, you will need to do so first. Check out the [Getting Started](/sdks/kotlin/getting-started) guide for more details.
+**OAuth**. Note if you have not enabled the Auth Proxy, you will need to do so first. Check out the [Getting Started](/solutions/embedded-wallets/integration-guide/kotlin/getting-started) guide for more details.
For OAuth2.0 providers, you will need to upload the client ID and secret in
the dashboard. Check out the [OAuth2.0
- providers](/sdks/kotlin/authentication/social-logins#oauth2-0-providers)
+ providers](/solutions/embedded-wallets/integration-guide/kotlin/authentication/social-logins#oauth2-0-providers)
section for more details.
+
\ No newline at end of file
diff --git a/sdks/kotlin/signing.mdx b/solutions/embedded-wallets/integration-guide/kotlin/signing.mdx
similarity index 100%
rename from sdks/kotlin/signing.mdx
rename to solutions/embedded-wallets/integration-guide/kotlin/signing.mdx
diff --git a/sdks/kotlin/sub-organization-customization.mdx b/solutions/embedded-wallets/integration-guide/kotlin/sub-organization-customization.mdx
similarity index 97%
rename from sdks/kotlin/sub-organization-customization.mdx
rename to solutions/embedded-wallets/integration-guide/kotlin/sub-organization-customization.mdx
index e95166f3..0d0bbbe1 100644
--- a/sdks/kotlin/sub-organization-customization.mdx
+++ b/solutions/embedded-wallets/integration-guide/kotlin/sub-organization-customization.mdx
@@ -160,5 +160,5 @@ Create a wallet (container) plus one or more accounts at signup.
## Next steps
-Now that you know how to customize the sub-orgs created in your Android application, check out the [Advanced API Requests](/sdks/kotlin/advanced-api-requests) guide to learn how to make advanced API requests to Turnkey's infrastructure.
+Now that you know how to customize the sub-orgs created in your Android application, check out the [Advanced API Requests](/solutions/embedded-wallets/integration-guide/kotlin/advanced-api-requests) guide to learn how to make advanced API requests to Turnkey's infrastructure.
This will help you build more complex features and functionalities in your app that go beyond what is included as helper functions in the SDK.
\ No newline at end of file
diff --git a/sdks/kotlin/using-embedded-wallets.mdx b/solutions/embedded-wallets/integration-guide/kotlin/using-embedded-wallets.mdx
similarity index 98%
rename from sdks/kotlin/using-embedded-wallets.mdx
rename to solutions/embedded-wallets/integration-guide/kotlin/using-embedded-wallets.mdx
index 45194950..1c7d6dde 100644
--- a/sdks/kotlin/using-embedded-wallets.mdx
+++ b/solutions/embedded-wallets/integration-guide/kotlin/using-embedded-wallets.mdx
@@ -8,7 +8,7 @@ sidebarTitle: "Using embedded wallets"
The Kotlin SDK allows you to create and manage embedded wallets in your Android application. This includes creating wallets, deriving wallet accounts, and accessing wallet information.
-Before we start, ensure you're familiar with the concepts of [Wallets](/concepts/wallets) and [Wallet Accounts](/concepts/wallets#accounts).
+Before we start, ensure you're familiar with the concepts of [Wallets](/features/wallets) and [Wallet Accounts](/features/wallets#accounts).
## Creating a wallet
@@ -394,4 +394,4 @@ class MainActivity : AppCompatActivity() {
## Next steps
-Check out the [Signing](/sdks/kotlin/signing) guide to learn how to sign transactions and messages with the embedded wallets you've created.
+Check out the [Signing](/solutions/embedded-wallets/integration-guide/kotlin/signing) guide to learn how to sign transactions and messages with the embedded wallets you've created.
diff --git a/solutions/embedded-wallets/integration-guide/overview.mdx b/solutions/embedded-wallets/integration-guide/overview.mdx
new file mode 100644
index 00000000..cee28c72
--- /dev/null
+++ b/solutions/embedded-wallets/integration-guide/overview.mdx
@@ -0,0 +1,145 @@
+---
+title: "Integration guide"
+description:
+ "An SDK-agnostic introduction to integrating Turnkey embedded wallets: how to choose your SDK, how
+ integrations are structured, and when to use the Auth Proxy."
+sidebarTitle: "Overview"
+---
+
+You've seen what Turnkey's embedded wallets can do. This page covers the concepts and architectural
+decisions that apply across all platforms before you dive into the platform-specific guides.
+
+## Choose your SDK
+
+Turnkey provides SDKs at different levels of abstraction. The right choice depends on your platform
+and how much you want pre-built for you.
+
+
+
+
+See [Embedded Wallets Overview](/solutions/embedded-wallets/overview#custody-models) for a breakdown of
+custodial models based on this architecture.
+
+## The Auth Proxy
+
+Creating a sub-organization and initiating email/SMS OTP flows require a request stamped by your
+root organization's API key. Traditionally this means hosting a backend.
+
+The **Auth Proxy** is Turnkey's managed backend for these operations. Enable it in the dashboard,
+configure your allowed origins and auth methods, and your frontend can call
+`https://authproxy.turnkey.com` directly — no server needed on your end.
+
+-
+
- You want to ship without standing up a backend +
- You're using the React or React Native Wallet Kit (they're designed around it) +
- Your auth flows are OTP, OAuth, and new-user signup +
-
+
- You already run a backend and want to keep signing logic there +
- You need flows the Auth Proxy doesn't cover +
- You need full control over request construction and error handling +
+
diff --git a/sdks/react-native/authentication/passkey.mdx b/solutions/embedded-wallets/integration-guide/react-native/authentication/passkey.mdx
similarity index 100%
rename from sdks/react-native/authentication/passkey.mdx
rename to solutions/embedded-wallets/integration-guide/react-native/authentication/passkey.mdx
diff --git a/sdks/react-native/authentication/social-logins.mdx b/solutions/embedded-wallets/integration-guide/react-native/authentication/social-logins.mdx
similarity index 96%
rename from sdks/react-native/authentication/social-logins.mdx
rename to solutions/embedded-wallets/integration-guide/react-native/authentication/social-logins.mdx
index 5e1b1d6f..d542280d 100644
--- a/sdks/react-native/authentication/social-logins.mdx
+++ b/solutions/embedded-wallets/integration-guide/react-native/authentication/social-logins.mdx
@@ -11,7 +11,7 @@ Using OAuth requires a bit of configuration in the Turnkey Dashboard and your ap
### Enabling OAuth
Navigate to the **Wallet Kit** section in the [Turnkey Dashboard](https://app.turnkey.com/dashboard/walletKit) and enable the
-**OAuth**. Note if you have not enabled the Auth Proxy, you will need to do so first. Check out the [Getting Started](/sdks/react-native/getting-started) guide for more details.
+**OAuth**. Note if you have not enabled the Auth Proxy, you will need to do so first. Check out the [Getting Started](/solutions/embedded-wallets/integration-guide/react-native/getting-started) guide for more details.
For OAuth2.0 providers, you will need to upload the client ID and secret in
the dashboard. Check out the [OAuth2.0
- providers](/sdks/react-native/authentication/social-logins#oauth2-0-providers)
+ providers](/solutions/embedded-wallets/integration-guide/react-native/authentication/social-logins#oauth2-0-providers)
section for more details.
diff --git a/sdks/react-native/getting-started.mdx b/solutions/embedded-wallets/integration-guide/react-native/getting-started.mdx
similarity index 97%
rename from sdks/react-native/getting-started.mdx
rename to solutions/embedded-wallets/integration-guide/react-native/getting-started.mdx
index fd0efcf2..d04b6310 100644
--- a/sdks/react-native/getting-started.mdx
+++ b/solutions/embedded-wallets/integration-guide/react-native/getting-started.mdx
@@ -6,7 +6,7 @@ sidebarTitle: "Getting started"
## Turnkey organization setup
-To start, you must create a Turnkey organization via the [Turnkey dashboard](https://app.turnkey.com). The steps to do so are described in the [Account Setup](/getting-started/quickstart) section.
+To start, you must create a Turnkey organization via the [Turnkey dashboard](https://app.turnkey.com). The steps to do so are described in the [Account Setup](/get-started/quickstart) section.
For this setup, we will be using Turnkey's Auth Proxy to handle authentication. We can enable and configure this through the Turnkey dashboard.
@@ -220,4 +220,4 @@ export default function RootLayout() {
## Next steps
-Ready to start building your app? Check out the [Authentication](/sdks/react-native/authentication/overview) guide to learn how to set up login or signup in React Native!
+Ready to start building your app? Check out the [Authentication](/solutions/embedded-wallets/integration-guide/react-native/authentication/overview) guide to learn how to set up login or signup in React Native!
diff --git a/solutions/embedded-wallets/integration-guide/react-native/overview.mdx b/solutions/embedded-wallets/integration-guide/react-native/overview.mdx
new file mode 100644
index 00000000..a55ebf52
--- /dev/null
+++ b/solutions/embedded-wallets/integration-guide/react-native/overview.mdx
@@ -0,0 +1,17 @@
+---
+title: "Overview"
+description: "Turnkey's Embedded Wallet Kit [`(@turnkey/react-native-wallet-kit)`](https://www.npmjs.com/package/@turnkey/react-native-wallet-kit) is the easiest way to integrate Turnkey’s Embedded Wallets into your React Native applications. It supports both backendless setups via Turnkey’s managed [Auth Proxy](https://docs.turnkey.com/reference/auth-proxy) and traditional backend-based architectures. Built on [`@turnkey/core`](https://www.npmjs.com/package/@turnkey/core), it provides easy-to-use functions exported from a hook, allowing you to quickly build secure embedded wallet experiences."
+sidebarTitle: "Overview"
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx'
+
+Find `@turnkey/react-native-wallet-kit` on [npm](https://www.npmjs.com/package/@turnkey/react-native-wallet-kit) or view the source code on [GitHub](https://github.com/tkhq/sdk/tree/main/packages/react-native-wallet-kit)! For a working reference implementation covering auth, wallet creation, export, and signing, see the [with-react-native-wallet-kit](https://github.com/tkhq/sdk/tree/main/examples/with-react-native-wallet-kit) example app.
+
+
+
diff --git a/sdks/react-native/signing.mdx b/solutions/embedded-wallets/integration-guide/react-native/signing.mdx
similarity index 100%
rename from sdks/react-native/signing.mdx
rename to solutions/embedded-wallets/integration-guide/react-native/signing.mdx
diff --git a/sdks/react-native/sub-organization-customization.mdx b/solutions/embedded-wallets/integration-guide/react-native/sub-organization-customization.mdx
similarity index 96%
rename from sdks/react-native/sub-organization-customization.mdx
rename to solutions/embedded-wallets/integration-guide/react-native/sub-organization-customization.mdx
index 0fda2b4b..6bb43939 100644
--- a/sdks/react-native/sub-organization-customization.mdx
+++ b/solutions/embedded-wallets/integration-guide/react-native/sub-organization-customization.mdx
@@ -109,5 +109,5 @@ For a complete list of available parameters, inspect the `CreateSubOrgParams` in
## Next steps
-Now that you know how to customize the sub-orgs created in your React Native application, check out the [Advanced API Requests](/sdks/react/advanced-api-requests) guide to learn how to make advanced API requests to Turnkey's infrastructure.
+Now that you know how to customize the sub-orgs created in your React Native application, check out the [Advanced API Requests](/solutions/embedded-wallets/integration-guide/react/advanced-api-requests) guide to learn how to make advanced API requests to Turnkey's infrastructure.
This will help you build more complex features and functionalities in your app that go beyond what is included as helper functions in the SDK.
diff --git a/sdks/react-native/using-embedded-wallets.mdx b/solutions/embedded-wallets/integration-guide/react-native/using-embedded-wallets.mdx
similarity index 97%
rename from sdks/react-native/using-embedded-wallets.mdx
rename to solutions/embedded-wallets/integration-guide/react-native/using-embedded-wallets.mdx
index d468c408..fd686701 100644
--- a/sdks/react-native/using-embedded-wallets.mdx
+++ b/solutions/embedded-wallets/integration-guide/react-native/using-embedded-wallets.mdx
@@ -8,7 +8,7 @@ sidebarTitle: "Using embedded wallets"
The Embedded Wallet Kit provides a straightforward way to create and manage embedded wallets in your React Native application. EWK offers function abstractions to easily create embedded wallets, derive accounts, import and export wallets and more.
-Before we start, ensure you're familiar with the concepts of [Wallets](/concepts/wallets) and [Wallet Accounts](/concepts/wallets#accounts).
+Before we start, ensure you're familiar with the concepts of [Wallets](/features/wallets) and [Wallet Accounts](/features/wallets#accounts).
## Creating an embedded wallet
@@ -314,4 +314,4 @@ const privateKeyId = await importPrivateKey({
## Next steps
-Check out the [Signing](/sdks/react-native/signing) guide to learn how to sign transactions and messages with the embedded wallets you've created.
+Check out the [Signing](/solutions/embedded-wallets/integration-guide/react-native/signing) guide to learn how to sign transactions and messages with the embedded wallets you've created.
diff --git a/sdks/react/advanced-api-requests.mdx b/solutions/embedded-wallets/integration-guide/react/advanced-api-requests.mdx
similarity index 94%
rename from sdks/react/advanced-api-requests.mdx
rename to solutions/embedded-wallets/integration-guide/react/advanced-api-requests.mdx
index 555168a3..1f8b6ac0 100644
--- a/sdks/react/advanced-api-requests.mdx
+++ b/solutions/embedded-wallets/integration-guide/react/advanced-api-requests.mdx
@@ -12,7 +12,7 @@ The Embedded Wallet Kit provides a wide variety of helper functions to abstract
To make advanced API requests, you can use the `httpClient` provided by the `useTurnkey` hook. This client is tied to the active session meaning stamping and organization context are automatically handled for you.
-You can see the [API Reference](/api-reference/overview) for a complete list of available API endpoints and their parameters. All of these can be accessed through the `httpClient`.
+You can see the [API Reference](/api-reference/overview/intro) for a complete list of available API endpoints and their parameters. All of these can be accessed through the `httpClient`.
Here's how you can use the `httpClient` to make a `signRawPayload` request to Turnkey:
diff --git a/sdks/react/advanced-backend-authentication.mdx b/solutions/embedded-wallets/integration-guide/react/advanced-backend-authentication.mdx
similarity index 95%
rename from sdks/react/advanced-backend-authentication.mdx
rename to solutions/embedded-wallets/integration-guide/react/advanced-backend-authentication.mdx
index 62b82980..16380f0d 100644
--- a/sdks/react/advanced-backend-authentication.mdx
+++ b/solutions/embedded-wallets/integration-guide/react/advanced-backend-authentication.mdx
@@ -163,11 +163,11 @@ const otpLogin = async (verificationToken: string) => {
};
```
-The private key generated from `createApiKeyPair` will be automatically stored in [`indexedDB`](/authentication/sessions#indexeddb-web-only-%3A) and used for stamping requests to Turnkey after authentication. You can learn more about stamps [here](/developer-reference/api-overview/stamps).
+The private key generated from `createApiKeyPair` will be automatically stored in [`indexedDB`](/features/authentication/sessions#indexeddb-web-only-%3A) and used for stamping requests to Turnkey after authentication. You can learn more about stamps [here](/api-reference/overview/stamps).
### Storing the session
-Login endpoints like `otpLogin` and `oauthLogin` will [return a session token in JWT format](/authentication/sessions#creating-a-read-write-session) that you need to store in your application. You can use the `storeSession` function from the `useTurnkey` hook to store the session token.
+Login endpoints like `otpLogin` and `oauthLogin` will [return a session token in JWT format](/features/authentication/sessions#creating-a-read-write-session) that you need to store in your application. You can use the `storeSession` function from the `useTurnkey` hook to store the session token.
```tsx
import { useTurnkey } from "@turnkey/react-wallet-kit";
diff --git a/sdks/react/auth.mdx b/solutions/embedded-wallets/integration-guide/react/auth.mdx
similarity index 92%
rename from sdks/react/auth.mdx
rename to solutions/embedded-wallets/integration-guide/react/auth.mdx
index 91526982..6909e11e 100644
--- a/sdks/react/auth.mdx
+++ b/solutions/embedded-wallets/integration-guide/react/auth.mdx
@@ -45,7 +45,7 @@ yarn run dev
-When a user clicks this button, they'll see a modal with the authentication options you configured during the [organization setup](/sdks/react/getting-started#turnkey-organization-setup).
+When a user clicks this button, they'll see a modal with the authentication options you configured during the [organization setup](/solutions/embedded-wallets/integration-guide/react/getting-started#turnkey-organization-setup).
+
+
diff --git a/sdks/swift/authentication/passkey.mdx b/solutions/embedded-wallets/integration-guide/swift/authentication/passkey.mdx
similarity index 93%
rename from sdks/swift/authentication/passkey.mdx
rename to solutions/embedded-wallets/integration-guide/swift/authentication/passkey.mdx
index 5bb7ce4d..4c5f5c9c 100644
--- a/sdks/swift/authentication/passkey.mdx
+++ b/solutions/embedded-wallets/integration-guide/swift/authentication/passkey.mdx
@@ -4,6 +4,8 @@ description: "Set up and implement passkey authentication using the Turnkey Swif
sidebarTitle: "Passkeys"
---
+import { FeatureCard } from '/snippets/feature-card.mdx'
+
## Overview
This guide shows how to implement passkey authentication in a Swift app using the Turnkey Swift SDK.
@@ -123,14 +125,4 @@ try await turnkey.signUpWithPasskey(
## Next steps
-
+
diff --git a/sdks/swift/signing.mdx b/solutions/embedded-wallets/integration-guide/swift/signing.mdx
similarity index 100%
rename from sdks/swift/signing.mdx
rename to solutions/embedded-wallets/integration-guide/swift/signing.mdx
diff --git a/sdks/swift/sub-organization-customization.mdx b/solutions/embedded-wallets/integration-guide/swift/sub-organization-customization.mdx
similarity index 98%
rename from sdks/swift/sub-organization-customization.mdx
rename to solutions/embedded-wallets/integration-guide/swift/sub-organization-customization.mdx
index 1c08e5d1..b126b959 100644
--- a/sdks/swift/sub-organization-customization.mdx
+++ b/solutions/embedded-wallets/integration-guide/swift/sub-organization-customization.mdx
@@ -185,4 +185,4 @@ try await turnkey.signUpWithPasskey(
## Next steps
-- [Advanced API requests](/sdks/swift/advanced-api-requests)
+- [Advanced API requests](/solutions/embedded-wallets/integration-guide/swift/advanced-api-requests)
diff --git a/sdks/swift/using-embedded-wallets.mdx b/solutions/embedded-wallets/integration-guide/swift/using-embedded-wallets.mdx
similarity index 96%
rename from sdks/swift/using-embedded-wallets.mdx
rename to solutions/embedded-wallets/integration-guide/swift/using-embedded-wallets.mdx
index 2c4ef32a..a4fd3805 100644
--- a/sdks/swift/using-embedded-wallets.mdx
+++ b/solutions/embedded-wallets/integration-guide/swift/using-embedded-wallets.mdx
@@ -8,13 +8,13 @@ sidebarTitle: "Using wallets"
The Turnkey Swift SDK provides a straightforward way to create and manage wallets in your Swift application. You can create wallets, derive accounts, import/export, and refresh wallet state from `TurnkeyContext`.
-Before you start, make sure you're familiar with [Wallets](/concepts/wallets) and [Wallet Accounts](/concepts/wallets#accounts).
+Before you start, make sure you're familiar with [Wallets](/features/wallets) and [Wallet Accounts](/features/wallets#accounts).
## Creation
There are two ways to create wallets and accounts:
-- During signup (sub-organization creation): Configure default wallet/accounts in your signup parameters so users get a wallet at account creation time. See [Sub-organization customization](/sdks/swift/sub-organization-customization) for how to set `CreateSubOrgParams` globally or per auth method.
+- During signup (sub-organization creation): Configure default wallet/accounts in your signup parameters so users get a wallet at account creation time. See [Sub-organization customization](/solutions/embedded-wallets/integration-guide/swift/sub-organization-customization) for how to set `CreateSubOrgParams` globally or per auth method.
- After authentication (active session): Create wallets programmatically using the `TurnkeyContext` once the user is authenticated.
### Wallet
diff --git a/sdks/typescript-frontend/advanced-api-requests.mdx b/solutions/embedded-wallets/integration-guide/typescript/advanced-api-requests.mdx
similarity index 94%
rename from sdks/typescript-frontend/advanced-api-requests.mdx
rename to solutions/embedded-wallets/integration-guide/typescript/advanced-api-requests.mdx
index bf0d638b..8ca8822c 100644
--- a/sdks/typescript-frontend/advanced-api-requests.mdx
+++ b/solutions/embedded-wallets/integration-guide/typescript/advanced-api-requests.mdx
@@ -12,7 +12,7 @@ The `@turnkey/core` provides a wide variety of helper functions to abstract inte
To make advanced API requests, you can use the `httpClient` provided in the `TurnkeyClient`. This client is tied to the active session meaning stamping and organization context are automatically handled for you.
-You can see the [API Reference](/api-reference/overview) for a complete list of available API endpoints and their parameters. All of these can be accessed through the `httpClient`.
+You can see the [API Reference](/api-reference/overview/intro) for a complete list of available API endpoints and their parameters. All of these can be accessed through the `httpClient`.
Here's how you can use the `httpClient` to make a `signRawPayload` request to Turnkey:
diff --git a/sdks/typescript-frontend/advanced-backend-authentication.mdx b/solutions/embedded-wallets/integration-guide/typescript/advanced-backend-authentication.mdx
similarity index 92%
rename from sdks/typescript-frontend/advanced-backend-authentication.mdx
rename to solutions/embedded-wallets/integration-guide/typescript/advanced-backend-authentication.mdx
index 4323e144..e5f53f0b 100644
--- a/sdks/typescript-frontend/advanced-backend-authentication.mdx
+++ b/solutions/embedded-wallets/integration-guide/typescript/advanced-backend-authentication.mdx
@@ -134,11 +134,11 @@ const otpLogin = async (verificationToken: string) => {
};
```
-The private key generated from `createApiKeyPair` will be automatically stored in [indexedDB](/authentication/sessions#indexeddb-web-only-%3A) on web environments or [secure storage](/authentication/sessions#securestorage-mobile-only) on React Native and used for stamping requests to Turnkey after authentication. You can learn more about stamps [here](/developer-reference/api-overview/stamps).
+The private key generated from `createApiKeyPair` will be automatically stored in [indexedDB](/features/authentication/sessions#indexeddb-web-only-%3A) on web environments or [secure storage](/features/authentication/sessions#securestorage-mobile-only) on React Native and used for stamping requests to Turnkey after authentication. You can learn more about stamps [here](/api-reference/overview/stamps).
### Storing the session
-Login endpoints like `otpLogin` and `oauthLogin` will [return a session token in JWT format](/authentication/sessions#creating-a-read-write-session) that you need to store in your application. You can use the `storeSession` function from the `TurnkeyClient` to store the session token.
+Login endpoints like `otpLogin` and `oauthLogin` will [return a session token in JWT format](/features/authentication/sessions#creating-a-read-write-session) that you need to store in your application. You can use the `storeSession` function from the `TurnkeyClient` to store the session token.
```tsx
const otpLogin = async (verificationToken: string) => {
diff --git a/sdks/typescript-frontend/auth.mdx b/solutions/embedded-wallets/integration-guide/typescript/auth.mdx
similarity index 100%
rename from sdks/typescript-frontend/auth.mdx
rename to solutions/embedded-wallets/integration-guide/typescript/auth.mdx
diff --git a/sdks/typescript-frontend/getting-started.mdx b/solutions/embedded-wallets/integration-guide/typescript/getting-started.mdx
similarity index 98%
rename from sdks/typescript-frontend/getting-started.mdx
rename to solutions/embedded-wallets/integration-guide/typescript/getting-started.mdx
index 35324818..fd074764 100644
--- a/sdks/typescript-frontend/getting-started.mdx
+++ b/solutions/embedded-wallets/integration-guide/typescript/getting-started.mdx
@@ -6,7 +6,7 @@ sidebarTitle: "Getting started"
## Turnkey organization setup
-To start, you must create a Turnkey organization via the [Turnkey dashboard](https://app.turnkey.com). The steps are described in the [Account Setup](/getting-started/quickstart) section.
+To start, you must create a Turnkey organization via the [Turnkey dashboard](https://app.turnkey.com). The steps are described in the [Account Setup](/get-started/quickstart) section.
For this setup, we will use Turnkey's **Auth Proxy** to handle authentication. You can enable and configure this through the Turnkey dashboard.
diff --git a/solutions/embedded-wallets/integration-guide/typescript/index.mdx b/solutions/embedded-wallets/integration-guide/typescript/index.mdx
new file mode 100644
index 00000000..84063afd
--- /dev/null
+++ b/solutions/embedded-wallets/integration-guide/typescript/index.mdx
@@ -0,0 +1,20 @@
+---
+title: "Overview"
+description:
+ "`@turnkey/core` is the core TypeScript client-side SDK for Turnkey's Embedded Wallets. It
+ provides a set of functions and utilities to interact with Turnkey's APIs, a powerful session
+ management system, built-in stampers, and a raw HTTP client for advanced use cases. This SDK is
+ designed to be used as a foundation for building Turnkey's Embedded Wallets in various frontend
+ frameworks, including React, React Native, Angular, Vue, and Svelte. If you're using React, please
+ consider using the [`@turnkey/react-wallet-kit`](/solutions/embedded-wallets/integration-guide/react/index) for a more tailored experience."
+sidebarTitle: "Overview"
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx'
+
+
+
diff --git a/sdks/typescript-frontend/legacy.mdx b/solutions/embedded-wallets/integration-guide/typescript/legacy.mdx
similarity index 85%
rename from sdks/typescript-frontend/legacy.mdx
rename to solutions/embedded-wallets/integration-guide/typescript/legacy.mdx
index 92fd79c9..d75659cb 100644
--- a/sdks/typescript-frontend/legacy.mdx
+++ b/solutions/embedded-wallets/integration-guide/typescript/legacy.mdx
@@ -3,9 +3,11 @@ title: "@turnkey/sdk-browser (legacy)"
sidebarTitle: "Legacy (@turnkey/sdk-browser)"
---
+import { FeatureCard } from '/snippets/feature-card.mdx'
+
`@turnkey/sdk-browser` is our legacy TypeScript SDK for building embedded wallet experiences in browser applications.
-This package will soon be discontinued, if you're starting a new project, we recommend using [`@turnkey/core`](/sdks/typescript-frontend/index) instead. If you're using React, please consider using the [`@turnkey/react-wallet-kit`](/sdks/react/getting-started) for a more tailored experience.
+This package will soon be discontinued, if you're starting a new project, we recommend using [`@turnkey/core`](/solutions/embedded-wallets/integration-guide/typescript/index) instead. If you're using React, please consider using the [`@turnkey/react-wallet-kit`](/solutions/embedded-wallets/integration-guide/react/getting-started) for a more tailored experience.
## Overview
@@ -303,26 +305,8 @@ const result = await turnkey.serverSign("method", [param1, param2]);
## Examples
-
+
diff --git a/solutions/embedded-wallets/overview.mdx b/solutions/embedded-wallets/overview.mdx
new file mode 100644
index 00000000..70bc6cd4
--- /dev/null
+++ b/solutions/embedded-wallets/overview.mdx
@@ -0,0 +1,96 @@
+---
+title: "Overview"
+---
+
+import { SolutionCard } from '/snippets/solution-card.mdx';
+
+## What are embedded wallets?
+
+An embedded wallet is a crypto wallet built directly into your application. Instead of asking users to install a browser extension or manage seed phrases, your app handles wallet creation, authentication, and signing behind the scenes. **Users interact with your product; the wallet is infrastructure they never have to think about.**
+
+## Why Turnkey for embedded wallets?
+
+Building embedded wallets from scratch means solving key management, multi-chain signing, authentication, custody models, and policy controls, all without exposing private keys. Turnkey handles this infrastructure so you can focus on your product.
+
+With Turnkey, you can:
+
+- Authenticate users via email, phone number, biometrics, social logins, or passkeys
+- Create and manage wallets across multiple chains
+- Configure custodial, non-custodial, or hybrid custody models
+- Control signing permissions with a programmable policy engine
+- Sponsor gas so users never need native tokens
+- Leverage pre-built UI components or build fully custom experiences
+- Import and export keys to support user sovereignty
+
+## How it works
+
+User authentication flows into a signed request to Turnkey. Inside the secure enclave, the
+[policy engine](/features/policies/overview) evaluates the request; key derivation and signing
+follow, and only the signature is returned. Your app can then broadcast the transaction through
+another provider or with
+[Turnkey Transaction Management](/features/transaction-management).
+
+
+ 
+
+
+### Custody models
+
+We recommend creating a Turnkey [sub-organization](/features/sub-organizations) for each end user. This gives every user a fully isolated environment with their own wallets, credentials, and policies.
+
+Private keys in Turnkey never leave the [secure enclave](/security/secure-enclaves). Custody is determined by who holds the credentials that can authorize the enclave to sign.
+
+- **Non-custodial:** The user is the sole party with signing authority. Only their authenticator (passkey, email, biometric) can authorize the enclave to produce a signature. Users can [export their keys](/features/wallets/export-wallets) to access assets independently of your application.
+- **Custodial:** Your application holds signing authority (via API key) and can authorize transactions without per-action user approval. Common for automated workflows like trading or subscription payments.
+- **Hybrid:** Both the user and your application hold credentials, but [policies](/features/policies/quickstart) define what each party can authorize. For example, the user controls asset transfers while your app handles gas sponsorship or scheduled operations.
+
+Turnkey supports all three models. The custody configuration is up to your application and can be tailored to match your product's requirements.
+
+### Security model
+
+- **Keys never leave the enclave.** Private keys live in [Trusted Execution Environments (TEEs)](/security/secure-enclaves). All derivation and signing happen inside verifiable infrastructure; only signatures are returned.
+- **Authenticator-bound requests.** Every sensitive operation is signed by a user-held authenticator (passkey, email, etc.). The enclave verifies the signature before performing the operation. See [Authentication Overview](/features/authentication/overview).
+- **Scoped, programmable control.** Choose non-custodial, hybrid, or app-controlled custody. [Policies](/features/policies/quickstart) and sub-organization isolation limit who can sign what.
+- **Trusted vs. untrusted separation.** Verification and execution run only inside secure enclaves. A breach of your app or backend does not expose keys or signing capability.
+
+For a deeper look, see [Security](/security/our-approach) and [Secure Enclaves](/security/secure-enclaves).
+
+## Building with Turnkey
+
+For React applications, the **[Embedded Wallet Kit (EWK)](/solutions/embedded-wallets/integration-guide/react/index)** is the recommended starting point. It provides pre-built auth and wallet UI components, a hook-based API, and requires no backend. It is the most opinionated path, designed to get you to a working embedded wallet with minimal configuration.
+
+Turnkey also provides SDKs for [React Native](/solutions/embedded-wallets/integration-guide/react-native/overview), [Swift](/solutions/embedded-wallets/integration-guide/swift/overview), [Kotlin](/solutions/embedded-wallets/integration-guide/kotlin/overview), and [Flutter](/solutions/embedded-wallets/integration-guide/flutter/index). For fully custom implementations, you can call the Turnkey API directly.
+
+See the [Integration Guide](/solutions/embedded-wallets/integration-guide/overview) to start building, or the [SDK Reference](/sdks/introduction) for detailed method documentation.
+
+## Use cases
+
+Embedded wallets serve different needs depending on who holds the wallet and how it's operated. Choose the pattern that matches what you're building.
+
+
+
+
+## Ready to build?
+
+- [Quickstart](/solutions/embedded-wallets/quickstart) -- explore the live demo, clone a starter app, or jump straight into building
+- [Integration Guide](/solutions/embedded-wallets/integration-guide/overview) -- step-by-step guides for React, React Native, Flutter, Swift, and Kotlin
+- [Documentation](/features/authentication/overview) -- dig into the underlying concepts: auth, wallets, policies, and more
diff --git a/solutions/embedded-wallets/quickstart.mdx b/solutions/embedded-wallets/quickstart.mdx
new file mode 100644
index 00000000..27b7f36f
--- /dev/null
+++ b/solutions/embedded-wallets/quickstart.mdx
@@ -0,0 +1,131 @@
+---
+title: "Embedded wallets quickstart"
+description:
+ "Three paths to get started with Turnkey's embedded wallets, whether you want to explore, clone,
+ or build from scratch."
+sidebarTitle: "Quickstart"
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx'
+
+Turnkey's embedded wallets let you add secure, fully-featured wallet experiences to your app. There
+are three ways to get started, depending on how hands-on you want to be.
+
+
+
+
+---
+
+## Explore the live demo
+
+The fastest way to see Turnkey embedded wallets in action. Our
+[live demo app](https://wallets.turnkey.com/) is a fully functional embedded wallet built with the
+Wallet Kit. Use it to try out authentication flows, wallet creation, transaction signing, and more,
+all from your browser with no setup.
+
+
+
+
+
+
+
+
+
+| Need | How Turnkey solves it |
+| :--- | :--- |
+| Risk separation between platforms | Turnkey never sees the encrypted data; your infrastructure never sees the encryption key. Both must be compromised. |
+| Decrypt recovery bundles without managing keys directly | Encryption key lives in the enclave; authenticate to export it on demand |
+| Caller retains control | Only the caller's authenticator (passkey, email, social login) can trigger key export |
+| Policy-gated access for sensitive operations | Quorum approval, scoped export policies, and audit trails for every key operation |
+
+### Implementation steps
+
+
+
diff --git a/solutions/key-management/enterprise-disaster-recovery.mdx b/solutions/key-management/enterprise-disaster-recovery.mdx
new file mode 100644
index 00000000..62162f2b
--- /dev/null
+++ b/solutions/key-management/enterprise-disaster-recovery.mdx
@@ -0,0 +1,96 @@
+---
+title: "Enterprise Disaster Recovery"
+description: "Import and recover wallets with end-to-end encryption, quorum-controlled access, and a cryptographic audit trail."
+---
+
+import { FeatureCard } from '/snippets/feature-card.mdx'
+import { SolutionCard } from '/snippets/solution-card.mdx'
+
+Back up wallets on Turnkey and recover them when you need to for incident response, provider migration, and redundancy. All key material is encrypted directly to Turnkey's secure enclave using [HPKE](/security/enclave-secure-channels), and every recovery operation is cryptographically stamped. For an overview of Turnkey's key management capabilities, see the [Key Management Overview](/solutions/key-management/overview).
+
+## Key implementation decisions
+
+| Decision | What to consider | Learn more |
+| :--- | :--- | :--- |
+| **Organization setup** | Create dedicated recovery users with limited permissions. Distribute authenticators (passkeys, YubiKeys) across geographic locations where possible. | [Organizations](/features/organizations) |
+| **Root quorum** | Require multiple approvers for sensitive operations to prevent any single credential compromise from triggering unauthorized recovery. | [Root Quorum](/features/users/root-quorum) |
+| **Recovery policies** | Restrict what can be done with recovered wallets: limit fund movement to allowed addresses, require multi-party approval, scope signing by chain or value. | [Policy Engine](/features/policies/overview), [Signing Control](/features/policies/examples/signing-control) |
+| **Import method** | Use the NodeJS server SDK for the full import flow including encryption and secure transport, or the React Wallet Kit for client-side import. | [Import Wallets](/features/wallets/import-wallets), [SDK Server](https://github.com/tkhq/sdk/tree/main/examples/import-in-node) |
+
+## Example: treasury recovery
+
+Import wallet keys into Turnkey's secure enclave ahead of time. If a key holder becomes unavailable or a hardware wallet fails, recover treasury assets with quorum-controlled access and policy-restricted fund movement.
+
+
+
+
+
+| Need | How Turnkey solves it |
+| :--- | :--- |
+| Import keys with no plaintext exposure in transit | All key material is encrypted directly to the enclave using [HPKE](/security/enclave-secure-channels). Plaintext never exists outside the enclave boundary. |
+| No single person can unilaterally move recovered funds | [Quorum approval](/features/users/root-quorum) requires multiple approvers for sensitive operations |
+| Restrict what can be done with recovered wallets | [Policies](/features/policies/overview) scope fund movement to allowed addresses, chains, and value thresholds |
+| Cryptographic audit trail | Every recovery operation is cryptographically stamped, ensuring recoveries cannot be tampered with |
+| Secondary signing path must always be available | Import backup copies of critical wallet keys so operations continue if a primary signer goes down |
+
+### Implementation steps
+
+
+
diff --git a/solutions/key-management/overview.mdx b/solutions/key-management/overview.mdx
new file mode 100644
index 00000000..f8ecba93
--- /dev/null
+++ b/solutions/key-management/overview.mdx
@@ -0,0 +1,76 @@
+---
+title: "Overview"
+---
+
+import { SolutionCard } from '/snippets/solution-card.mdx';
+
+## What is key management?
+
+Turnkey provides infrastructure to store, recover, and operate on cryptographic keys beyond just wallet use cases. Instead of managing raw key material in your own infrastructure, your application delegates key storage to Turnkey's secure enclaves and controls access through programmable policies. **You define who can use a key and under what conditions; Turnkey ensures the key material is never exposed.**
+
+## Why Turnkey for key management?
+
+Protecting cryptographic keys means solving for secure storage, access control, disaster recovery, and auditability. Turnkey's infrastructure handles this so your keys remain protected throughout their lifecycle.
+
+With Turnkey, you can:
+
+- Store and [import](/security/enclave-secure-channels) cryptographic keys in hardware-backed [secure enclaves](/security/secure-enclaves) where key material never exists in plaintext outside the enclave boundary
+- Gate key access and export through a programmable [policy engine](/features/policies/overview), including [quorum approval](/features/users/root-quorum) for sensitive operations
+- Authenticate key access through multiple methods including API keys, [passkeys](/features/authentication/passkeys/introduction), [social logins](/features/authentication/social-logins), [email](/features/authentication/email), and [SMS OTP](/features/authentication/sms)
+- Maintain a cryptographic audit trail where every key operation is stamped and verifiable
+- Distribute trust between your infrastructure and Turnkey so no single party can access plaintext material
+
+## How it works
+
+Your backend authenticates to Turnkey via API key. The [policy engine](/features/policies/overview) evaluates every request inside the secure enclave before any key operation executes. Keys are stored and operated on entirely within the enclave. Only derived outputs (public keys, encrypted export bundles, and operation results) are returned.
+
+### Access control model
+
+Key management is configured through an [organization](/features/organizations) with users, tags, and policies to control access:
+
+- **Users** representing human operators and automated services, each with their own credentials (API keys, passkeys)
+- **Tags** grouping users by role (e.g. `recovery-admin`, `backup-operator`)
+- **Policies** controlling who can access keys and under what conditions: by key ID, operation type, approval threshold, or any combination
+
+Turnkey is deny-by-default. If no policy explicitly allows an action, it is rejected. See [Policies](/features/policies/overview) and [Policy Language](/features/policies/language).
+
+### Security model
+
+- **Keys never leave the enclave.** Cryptographic keys live in [Trusted Execution Environments (TEEs)](/security/secure-enclaves). All key operations happen inside verifiable infrastructure; only derived outputs are returned.
+- **End-to-end encryption for import and export.** Key material in transit is encrypted directly to the enclave using [HPKE](/security/enclave-secure-channels). Plaintext never exists outside the enclave boundary.
+- **Policy-gated access.** Every key operation is evaluated against policies in the enclave. Users and services can only perform actions they have been explicitly authorized for.
+- **Trusted vs. untrusted separation.** A breach of your backend does not expose keys. The enclave enforces policies independently of your infrastructure.
+
+For a deeper look, see [Security](/security/our-approach) and [Secure Enclaves](/security/secure-enclaves).
+
+## Building with Turnkey
+
+Key management integrations are backend-driven. Use Turnkey's server SDKs to store keys, manage policies, and handle import and export operations programmatically from your infrastructure.
+
+Server SDKs are available for [TypeScript](/solutions/company-wallets/integration-guide/javascript-server), [Go](/solutions/company-wallets/integration-guide/golang), [Ruby](/solutions/company-wallets/integration-guide/ruby), [Python](/solutions/company-wallets/integration-guide/python), and [Rust](/solutions/company-wallets/integration-guide/rust). For full control, you can call the [Turnkey API](/api-reference/overview/intro) directly.
+
+The [Turnkey Dashboard](https://app.turnkey.com) provides an interface for managing organizations, users, and policies.
+
+## Use cases
+
+Key management serves different needs depending on how your application uses cryptographic keys. Choose the pattern that matches your requirements.
+
+
+
+
+## Ready to build?
+
+- [Policy Quickstart](/features/policies/quickstart) -- define access controls and approval requirements
+- [SDK Reference](/sdks/introduction) -- server SDKs for TypeScript, Go, Ruby, Python, and Rust
diff --git a/solutions/overview.mdx b/solutions/overview.mdx
new file mode 100644
index 00000000..4724bc32
--- /dev/null
+++ b/solutions/overview.mdx
@@ -0,0 +1,85 @@
+---
+title: "Introducing Turnkey Solutions"
+description: "Structured starting points for building onchain with Turnkey"
+---
+
+import { SolutionCard } from '/snippets/solution-card.mdx';
+
+To help you build quickly, we've packaged common patterns like wallet provisioning, policy enforcement, and transaction flows into easy integration paths called Turnkey Solutions. Each Solution is built on Turnkey's underlying primitives, so you're never locked into a rigid workflow and can always go deeper when you need more flexibility.
+
+Whether you're building consumer apps, business tooling, or AI-powered systems, there's a solution designed for your use case.
+
+---
+
+## Embedded Wallets
+
+Wallet experiences built directly into your product. Users authenticate with email, passkeys, or social login — you control the UX.
+
+
+
+
+---
+
+## Company Wallets
+
+Wallets your organization operates for onchain automation — high-volume signing with programmable controls.
+
+
+
+
+---
+
+## Key Management
+
+Enterprise-grade security for your most sensitive keys — hardware-backed with programmable access controls.
+
+
+
diff --git a/step1-move-files.sh b/step1-move-files.sh
new file mode 100644
index 00000000..6e782c7a
--- /dev/null
+++ b/step1-move-files.sh
@@ -0,0 +1,296 @@
+#!/usr/bin/env bash
+#
+# step1-move-files.sh
+# Phase 3 file moves -- 187 total (Generated from url-mapping-draft.md)
+#
+# Usage: cd /Users/graham/Documents/DocsRepo/docs && bash step1-move-files.sh
+#
+set -euo pipefail
+
+cd /Users/graham/Documents/DocsRepo/docs/
+
+# =============================================================================
+# Solutions (96 moves)
+# =============================================================================
+
+# --- Embedded Wallets overview / top-level pages ---
+mkdir -p "solutions/embedded-wallets"
+git mv "embedded-wallets/overview.mdx" "solutions/embedded-wallets/overview.mdx"
+git mv "embedded-wallets/code-examples/embedded-consumer-wallet.mdx" "solutions/embedded-wallets/embedded-consumer-wallet.mdx"
+git mv "products/embedded-business-wallets/overview.mdx" "solutions/embedded-wallets/embedded-business-wallets.mdx"
+git mv "embedded-wallets/embedded-waas.mdx" "solutions/embedded-wallets/embedded-waas.mdx"
+git mv "getting-started/embedded-wallet-quickstart.mdx" "solutions/embedded-wallets/quickstart.mdx"
+
+# --- Embedded Wallets integration guide overview ---
+mkdir -p "solutions/embedded-wallets/integration-guide"
+git mv "embedded-wallets/integration-guide/overview.mdx" "solutions/embedded-wallets/integration-guide/overview.mdx"
+
+# --- React SDK -> solutions/embedded-wallets/integration-guide/react ---
+mkdir -p "solutions/embedded-wallets/integration-guide/react/using-external-wallets"
+git mv "sdks/react/index.mdx" "solutions/embedded-wallets/integration-guide/react/index.mdx"
+git mv "sdks/react/getting-started.mdx" "solutions/embedded-wallets/integration-guide/react/getting-started.mdx"
+git mv "sdks/react/auth.mdx" "solutions/embedded-wallets/integration-guide/react/auth.mdx"
+git mv "sdks/react/using-embedded-wallets.mdx" "solutions/embedded-wallets/integration-guide/react/using-embedded-wallets.mdx"
+git mv "sdks/react/using-external-wallets/overview.mdx" "solutions/embedded-wallets/integration-guide/react/using-external-wallets/overview.mdx"
+git mv "sdks/react/using-external-wallets/authentication.mdx" "solutions/embedded-wallets/integration-guide/react/using-external-wallets/authentication.mdx"
+git mv "sdks/react/using-external-wallets/connecting.mdx" "solutions/embedded-wallets/integration-guide/react/using-external-wallets/connecting.mdx"
+git mv "sdks/react/signing.mdx" "solutions/embedded-wallets/integration-guide/react/signing.mdx"
+git mv "sdks/react/ui-customization.mdx" "solutions/embedded-wallets/integration-guide/react/ui-customization.mdx"
+git mv "sdks/react/sub-organization-customization.mdx" "solutions/embedded-wallets/integration-guide/react/sub-organization-customization.mdx"
+git mv "sdks/react/advanced-api-requests.mdx" "solutions/embedded-wallets/integration-guide/react/advanced-api-requests.mdx"
+git mv "sdks/react/advanced-backend-authentication.mdx" "solutions/embedded-wallets/integration-guide/react/advanced-backend-authentication.mdx"
+git mv "sdks/react/migrating-sdk-react.mdx" "solutions/embedded-wallets/integration-guide/react/migrating-sdk-react.mdx"
+git mv "sdks/react/troubleshooting.mdx" "solutions/embedded-wallets/integration-guide/react/troubleshooting.mdx"
+git mv "sdks/react/legacy.mdx" "solutions/embedded-wallets/integration-guide/react/legacy.mdx"
+
+# --- React Native SDK -> solutions/embedded-wallets/integration-guide/react-native ---
+mkdir -p "solutions/embedded-wallets/integration-guide/react-native/authentication"
+git mv "sdks/react-native/overview.mdx" "solutions/embedded-wallets/integration-guide/react-native/overview.mdx"
+git mv "sdks/react-native/getting-started.mdx" "solutions/embedded-wallets/integration-guide/react-native/getting-started.mdx"
+git mv "sdks/react-native/authentication/overview.mdx" "solutions/embedded-wallets/integration-guide/react-native/authentication/overview.mdx"
+git mv "sdks/react-native/authentication/email-sms.mdx" "solutions/embedded-wallets/integration-guide/react-native/authentication/email-sms.mdx"
+git mv "sdks/react-native/authentication/passkey.mdx" "solutions/embedded-wallets/integration-guide/react-native/authentication/passkey.mdx"
+git mv "sdks/react-native/authentication/social-logins.mdx" "solutions/embedded-wallets/integration-guide/react-native/authentication/social-logins.mdx"
+git mv "sdks/react-native/sub-organization-customization.mdx" "solutions/embedded-wallets/integration-guide/react-native/sub-organization-customization.mdx"
+git mv "sdks/react-native/using-embedded-wallets.mdx" "solutions/embedded-wallets/integration-guide/react-native/using-embedded-wallets.mdx"
+git mv "sdks/react-native/signing.mdx" "solutions/embedded-wallets/integration-guide/react-native/signing.mdx"
+git mv "sdks/react-native/advanced-api-requests.mdx" "solutions/embedded-wallets/integration-guide/react-native/advanced-api-requests.mdx"
+
+# --- TypeScript Frontend SDK -> solutions/embedded-wallets/integration-guide/typescript ---
+mkdir -p "solutions/embedded-wallets/integration-guide/typescript"
+git mv "sdks/typescript-frontend/index.mdx" "solutions/embedded-wallets/integration-guide/typescript/index.mdx"
+git mv "sdks/typescript-frontend/getting-started.mdx" "solutions/embedded-wallets/integration-guide/typescript/getting-started.mdx"
+git mv "sdks/typescript-frontend/auth.mdx" "solutions/embedded-wallets/integration-guide/typescript/auth.mdx"
+git mv "sdks/typescript-frontend/advanced-backend-authentication.mdx" "solutions/embedded-wallets/integration-guide/typescript/advanced-backend-authentication.mdx"
+git mv "sdks/typescript-frontend/advanced-api-requests.mdx" "solutions/embedded-wallets/integration-guide/typescript/advanced-api-requests.mdx"
+git mv "sdks/typescript-frontend/legacy.mdx" "solutions/embedded-wallets/integration-guide/typescript/legacy.mdx"
+
+# --- Flutter SDK -> solutions/embedded-wallets/integration-guide/flutter ---
+mkdir -p "solutions/embedded-wallets/integration-guide/flutter/authentication"
+git mv "sdks/flutter/index.mdx" "solutions/embedded-wallets/integration-guide/flutter/index.mdx"
+git mv "sdks/flutter/getting-started.mdx" "solutions/embedded-wallets/integration-guide/flutter/getting-started.mdx"
+git mv "sdks/flutter/authentication/overview.mdx" "solutions/embedded-wallets/integration-guide/flutter/authentication/overview.mdx"
+git mv "sdks/flutter/authentication/email-sms.mdx" "solutions/embedded-wallets/integration-guide/flutter/authentication/email-sms.mdx"
+git mv "sdks/flutter/authentication/passkey.mdx" "solutions/embedded-wallets/integration-guide/flutter/authentication/passkey.mdx"
+git mv "sdks/flutter/authentication/social-logins.mdx" "solutions/embedded-wallets/integration-guide/flutter/authentication/social-logins.mdx"
+git mv "sdks/flutter/sub-organization-customization.mdx" "solutions/embedded-wallets/integration-guide/flutter/sub-organization-customization.mdx"
+git mv "sdks/flutter/using-embedded-wallets.mdx" "solutions/embedded-wallets/integration-guide/flutter/using-embedded-wallets.mdx"
+git mv "sdks/flutter/signing.mdx" "solutions/embedded-wallets/integration-guide/flutter/signing.mdx"
+git mv "sdks/flutter/advanced-api-requests.mdx" "solutions/embedded-wallets/integration-guide/flutter/advanced-api-requests.mdx"
+
+# --- Swift SDK -> solutions/embedded-wallets/integration-guide/swift ---
+mkdir -p "solutions/embedded-wallets/integration-guide/swift/authentication"
+git mv "sdks/swift/overview.mdx" "solutions/embedded-wallets/integration-guide/swift/overview.mdx"
+git mv "sdks/swift/getting-started.mdx" "solutions/embedded-wallets/integration-guide/swift/getting-started.mdx"
+git mv "sdks/swift/authentication/overview.mdx" "solutions/embedded-wallets/integration-guide/swift/authentication/overview.mdx"
+git mv "sdks/swift/authentication/email-sms.mdx" "solutions/embedded-wallets/integration-guide/swift/authentication/email-sms.mdx"
+git mv "sdks/swift/authentication/passkey.mdx" "solutions/embedded-wallets/integration-guide/swift/authentication/passkey.mdx"
+git mv "sdks/swift/authentication/social-logins.mdx" "solutions/embedded-wallets/integration-guide/swift/authentication/social-logins.mdx"
+git mv "sdks/swift/signing.mdx" "solutions/embedded-wallets/integration-guide/swift/signing.mdx"
+git mv "sdks/swift/sub-organization-customization.mdx" "solutions/embedded-wallets/integration-guide/swift/sub-organization-customization.mdx"
+git mv "sdks/swift/advanced-api-requests.mdx" "solutions/embedded-wallets/integration-guide/swift/advanced-api-requests.mdx"
+git mv "sdks/swift/using-embedded-wallets.mdx" "solutions/embedded-wallets/integration-guide/swift/using-embedded-wallets.mdx"
+git mv "sdks/swift/advanced-backend-authentication.mdx" "solutions/embedded-wallets/integration-guide/swift/advanced-backend-authentication.mdx"
+
+# --- Kotlin SDK -> solutions/embedded-wallets/integration-guide/kotlin ---
+mkdir -p "solutions/embedded-wallets/integration-guide/kotlin/authentication"
+git mv "sdks/kotlin/overview.mdx" "solutions/embedded-wallets/integration-guide/kotlin/overview.mdx"
+git mv "sdks/kotlin/getting-started.mdx" "solutions/embedded-wallets/integration-guide/kotlin/getting-started.mdx"
+git mv "sdks/kotlin/authentication/overview.mdx" "solutions/embedded-wallets/integration-guide/kotlin/authentication/overview.mdx"
+git mv "sdks/kotlin/authentication/email-sms.mdx" "solutions/embedded-wallets/integration-guide/kotlin/authentication/email-sms.mdx"
+git mv "sdks/kotlin/authentication/passkey.mdx" "solutions/embedded-wallets/integration-guide/kotlin/authentication/passkey.mdx"
+git mv "sdks/kotlin/authentication/social-logins.mdx" "solutions/embedded-wallets/integration-guide/kotlin/authentication/social-logins.mdx"
+git mv "sdks/kotlin/authentication/rp-id-setup.mdx" "solutions/embedded-wallets/integration-guide/kotlin/authentication/rp-id-setup.mdx"
+git mv "sdks/kotlin/sub-organization-customization.mdx" "solutions/embedded-wallets/integration-guide/kotlin/sub-organization-customization.mdx"
+git mv "sdks/kotlin/using-embedded-wallets.mdx" "solutions/embedded-wallets/integration-guide/kotlin/using-embedded-wallets.mdx"
+git mv "sdks/kotlin/signing.mdx" "solutions/embedded-wallets/integration-guide/kotlin/signing.mdx"
+git mv "sdks/kotlin/advanced-api-requests.mdx" "solutions/embedded-wallets/integration-guide/kotlin/advanced-api-requests.mdx"
+
+# --- Company Wallets ---
+mkdir -p "solutions/company-wallets/integration-guide"
+git mv "company-wallets/overview.mdx" "solutions/company-wallets/overview.mdx"
+git mv "company-wallets/code-examples/payment-orchestration.mdx" "solutions/company-wallets/payment-orchestration.mdx"
+git mv "company-wallets/code-examples/smart-contract-management.mdx" "solutions/company-wallets/smart-contract-management.mdx"
+git mv "company-wallets/use-cases/agentic-wallets.mdx" "solutions/company-wallets/agentic-wallets.mdx"
+git mv "getting-started/company-wallets-quickstart.mdx" "solutions/company-wallets/quickstart.mdx"
+git mv "company-wallets/integration-guide/overview.mdx" "solutions/company-wallets/integration-guide/overview.mdx"
+git mv "sdks/javascript-server.mdx" "solutions/company-wallets/integration-guide/javascript-server.mdx"
+git mv "sdks/golang.mdx" "solutions/company-wallets/integration-guide/golang.mdx"
+git mv "sdks/ruby.mdx" "solutions/company-wallets/integration-guide/ruby.mdx"
+git mv "sdks/rust.mdx" "solutions/company-wallets/integration-guide/rust.mdx"
+git mv "sdks/python.mdx" "solutions/company-wallets/integration-guide/python.mdx"
+
+# --- Key Management ---
+mkdir -p "solutions/key-management"
+git mv "products/key-management/overview.mdx" "solutions/key-management/overview.mdx"
+git mv "products/key-management/examples/encryption-key-storage.mdx" "solutions/key-management/encryption-key-storage.mdx"
+git mv "products/key-management/examples/enterprise-disaster-recovery.mdx" "solutions/key-management/enterprise-disaster-recovery.mdx"
+
+# --- Cookbooks ---
+mkdir -p "solutions/cookbooks"
+git mv "cookbook/landing.mdx" "solutions/cookbooks/landing.mdx"
+git mv "cookbook/morpho.mdx" "solutions/cookbooks/morpho.mdx"
+git mv "cookbook/aave.mdx" "solutions/cookbooks/aave.mdx"
+git mv "cookbook/breeze.mdx" "solutions/cookbooks/breeze.mdx"
+git mv "cookbook/yieldxyz.mdx" "solutions/cookbooks/yieldxyz.mdx"
+git mv "cookbook/jupiter.mdx" "solutions/cookbooks/jupiter.mdx"
+git mv "cookbook/lifi.mdx" "solutions/cookbooks/lifi.mdx"
+git mv "cookbook/0x.mdx" "solutions/cookbooks/0x.mdx"
+git mv "cookbook/relay.mdx" "solutions/cookbooks/relay.mdx"
+git mv "cookbook/polymarket-builders.mdx" "solutions/cookbooks/polymarket-builders.mdx"
+git mv "cookbook/base-builder-codes.mdx" "solutions/cookbooks/base-builder-codes.mdx"
+git mv "cookbook/brale.mdx" "solutions/cookbooks/brale.mdx"
+git mv "reference/tron-gasless-transactions.mdx" "solutions/cookbooks/tron-gasless-transactions.mdx"
+
+# =============================================================================
+# Get started (7 moves)
+# =============================================================================
+
+mkdir -p "get-started"
+git mv "home.mdx" "get-started/about-turnkey.mdx"
+git mv "getting-started/quickstart.mdx" "get-started/quickstart.mdx"
+git mv "developer-reference/using-llms.mdx" "get-started/using-llms.mdx"
+git mv "ai/skills.mdx" "get-started/ai-skills.mdx"
+git mv "getting-started/examples.mdx" "get-started/examples.mdx"
+git mv "production-checklist/production-checklist.mdx" "get-started/production-checklist.mdx"
+git mv "production-checklist/backup-recovery.mdx" "get-started/backup-recovery.mdx"
+
+# =============================================================================
+# Features (71 moves)
+# =============================================================================
+
+# --- Organizations & Sub-organizations ---
+mkdir -p "features"
+git mv "concepts/organizations.mdx" "features/organizations.mdx"
+git mv "concepts/sub-organizations.mdx" "features/sub-organizations.mdx"
+
+# --- Users ---
+mkdir -p "features/users"
+git mv "concepts/users/introduction.mdx" "features/users/introduction.mdx"
+git mv "concepts/users/credentials.mdx" "features/users/credentials.mdx"
+git mv "concepts/users/root-quorum.mdx" "features/users/root-quorum.mdx"
+git mv "concepts/users/best-practices.mdx" "features/users/best-practices.mdx"
+
+# --- Authentication ---
+mkdir -p "features/authentication/passkeys"
+git mv "authentication/overview.mdx" "features/authentication/overview.mdx"
+git mv "authentication/email.mdx" "features/authentication/email.mdx"
+git mv "authentication/social-logins.mdx" "features/authentication/social-logins.mdx"
+git mv "authentication/sms.mdx" "features/authentication/sms.mdx"
+git mv "authentication/passkeys/introduction.mdx" "features/authentication/passkeys/introduction.mdx"
+git mv "authentication/passkeys/integration.mdx" "features/authentication/passkeys/integration.mdx"
+git mv "authentication/passkeys/options.mdx" "features/authentication/passkeys/options.mdx"
+git mv "authentication/passkeys/native.mdx" "features/authentication/passkeys/native.mdx"
+git mv "authentication/passkeys/discoverable-vs-non-discoverable.mdx" "features/authentication/passkeys/discoverable-vs-non-discoverable.mdx"
+git mv "authentication/backend-setup.mdx" "features/authentication/backend-setup.mdx"
+git mv "authentication/bring-your-own-auth.mdx" "features/authentication/bring-your-own-auth.mdx"
+git mv "reference/auth-proxy.mdx" "features/authentication/auth-proxy.mdx"
+git mv "authentication/sessions.mdx" "features/authentication/sessions.mdx"
+git mv "authentication/proxying-signed-requests.mdx" "features/authentication/proxying-signed-requests.mdx"
+
+# --- Wallets ---
+mkdir -p "features/wallets"
+git mv "concepts/wallets.mdx" "features/wallets.mdx"
+git mv "products/company-wallets/features/import-wallets.mdx" "features/wallets/import-wallets.mdx"
+git mv "products/company-wallets/features/export-wallets.mdx" "features/wallets/export-wallets.mdx"
+git mv "wallets/pregenerated-wallets.mdx" "features/wallets/pregenerated-wallets.mdx"
+git mv "wallets/claim-links.mdx" "features/wallets/claim-links.mdx"
+git mv "embedded-wallets/send-crypto-via-url.mdx" "features/wallets/send-crypto-via-url.mdx"
+git mv "reference/aa-wallets.mdx" "features/wallets/aa-wallets.mdx"
+
+# --- Networks ---
+mkdir -p "features/networks"
+git mv "networks/overview.mdx" "features/networks/overview.mdx"
+git mv "networks/ethereum.mdx" "features/networks/ethereum.mdx"
+git mv "networks/solana.mdx" "features/networks/solana.mdx"
+git mv "networks/solana-transaction-construction.mdx" "features/networks/solana-transaction-construction.mdx"
+git mv "networks/solana-rent-refunds.mdx" "features/networks/solana-rent-refunds.mdx"
+git mv "networks/bitcoin.mdx" "features/networks/bitcoin.mdx"
+git mv "networks/spark.mdx" "features/networks/spark.mdx"
+git mv "networks/hyperliquid.mdx" "features/networks/hyperliquid.mdx"
+git mv "networks/cosmos.mdx" "features/networks/cosmos.mdx"
+git mv "networks/tron.mdx" "features/networks/tron.mdx"
+git mv "networks/sui.mdx" "features/networks/sui.mdx"
+git mv "networks/sei.mdx" "features/networks/sei.mdx"
+git mv "networks/stacks.mdx" "features/networks/stacks.mdx"
+git mv "networks/aptos.mdx" "features/networks/aptos.mdx"
+git mv "networks/tempo.mdx" "features/networks/tempo.mdx"
+git mv "networks/movement.mdx" "features/networks/movement.mdx"
+git mv "networks/iota.mdx" "features/networks/iota.mdx"
+git mv "networks/doge.mdx" "features/networks/doge.mdx"
+git mv "networks/others.mdx" "features/networks/others.mdx"
+
+# --- Policies ---
+mkdir -p "features/policies/examples"
+mkdir -p "features/policies/delegated-access"
+git mv "concepts/policies/overview.mdx" "features/policies/overview.mdx"
+git mv "concepts/policies/quickstart.mdx" "features/policies/quickstart.mdx"
+git mv "concepts/policies/language.mdx" "features/policies/language.mdx"
+git mv "concepts/policies/smart-contract-interfaces.mdx" "features/policies/smart-contract-interfaces.mdx"
+git mv "concepts/policies/examples/access-control.mdx" "features/policies/examples/access-control.mdx"
+git mv "company-wallets/co-signing-transactions.mdx" "features/policies/examples/co-signing-transactions.mdx"
+git mv "concepts/policies/examples/signing-control.mdx" "features/policies/examples/signing-control.mdx"
+git mv "concepts/policies/examples/ethereum.mdx" "features/policies/examples/ethereum.mdx"
+git mv "concepts/policies/examples/solana.mdx" "features/policies/examples/solana.mdx"
+git mv "concepts/policies/examples/tron.mdx" "features/policies/examples/tron.mdx"
+git mv "concepts/policies/examples/bitcoin.mdx" "features/policies/examples/bitcoin.mdx"
+git mv "concepts/policies/examples/tempo.mdx" "features/policies/examples/tempo.mdx"
+git mv "concepts/policies/delegated-access-overview.mdx" "features/policies/delegated-access/overview.mdx"
+git mv "concepts/policies/delegated-access-frontend.mdx" "features/policies/delegated-access/frontend.mdx"
+git mv "concepts/policies/delegated-access-backend.mdx" "features/policies/delegated-access/backend.mdx"
+git mv "products/embedded-wallets/features/agentic-wallets.mdx" "features/policies/delegated-access/agentic-wallets.mdx"
+
+# --- Transaction Management ---
+mkdir -p "features/transaction-management"
+git mv "concepts/transaction-management.mdx" "features/transaction-management.mdx"
+git mv "concepts/broadcasting.mdx" "features/transaction-management/broadcasting.mdx"
+git mv "embedded-wallets/code-examples/sending-sponsored-transactions.mdx" "features/transaction-management/sending-sponsored-transactions.mdx"
+git mv "embedded-wallets/code-examples/sending-sponsored-solana-transactions.mdx" "features/transaction-management/sending-sponsored-solana-transactions.mdx"
+git mv "concepts/balances.mdx" "features/transaction-management/balances.mdx"
+git mv "wallets/fiat-on-ramp.mdx" "features/transaction-management/fiat-on-ramp.mdx"
+
+# --- Verifiable Cloud ---
+mkdir -p "features/verifiable-cloud"
+git mv "products/verifiable-cloud/overview.mdx" "features/verifiable-cloud/overview.mdx"
+git mv "products/verifiable-cloud/onboarding.mdx" "features/verifiable-cloud/onboarding.mdx"
+git mv "getting-started/verifiable-cloud-quickstart.mdx" "features/verifiable-cloud/quickstart.mdx"
+
+# =============================================================================
+# Reference (4 moves)
+# =============================================================================
+
+mkdir -p "reference"
+git mv "concepts/resource-limits.mdx" "reference/resource-limits.mdx"
+git mv "developer-reference/webhooks.mdx" "reference/webhooks.mdx"
+git mv "getting-started/migration-guide.mdx" "reference/migration-guide.mdx"
+git mv "faq.mdx" "reference/faq.mdx"
+
+# =============================================================================
+# API reference (3 moves)
+# =============================================================================
+
+mkdir -p "api-reference/overview"
+git mv "developer-reference/api-overview/intro.mdx" "api-reference/overview/intro.mdx"
+git mv "developer-reference/api-overview/stamps.mdx" "api-reference/overview/stamps.mdx"
+git mv "developer-reference/api-overview/errors.mdx" "api-reference/overview/errors.mdx"
+
+# =============================================================================
+# SDK reference (4 moves)
+# =============================================================================
+
+mkdir -p "sdks/web3"
+mkdir -p "sdks/advanced"
+git mv "category/web3-libraries.mdx" "sdks/web3/overview.mdx"
+git mv "wallets/wagmi.mdx" "sdks/web3/wagmi.mdx"
+git mv "category/advanced.mdx" "sdks/advanced/overview.mdx"
+git mv "embedded-wallets/code-examples/client-side-signing.mdx" "sdks/advanced/client-side-signing.mdx"
+
+# =============================================================================
+# Security (2 moves)
+# =============================================================================
+
+mkdir -p "security"
+git mv "category/security.mdx" "security/overview.mdx"
+git mv "products/company-wallets/features/security/remote-attestation.mdx" "security/remote-attestation.mdx"
+
+echo "Done. Moved 187 files."
diff --git a/step2-update-docsjson.py b/step2-update-docsjson.py
new file mode 100644
index 00000000..237f81fb
--- /dev/null
+++ b/step2-update-docsjson.py
@@ -0,0 +1,354 @@
+#!/usr/bin/env python3
+"""
+Step 2: Update docs.json navigation paths based on Phase 3 URL mapping.
+
+This script reads docs.json, walks the "navigation" section recursively,
+and replaces old paths with new paths according to the Phase 3 mapping table.
+Only the "navigation" section is modified; redirects and everything else
+are left untouched.
+
+Usage:
+ python step2-update-docsjson.py
+"""
+
+import json
+import sys
+from pathlib import Path
+
+# ---------------------------------------------------------------------------
+# Phase 3 mapping: old path -> new path (only rows where Changed = Yes)
+# Paths use the docs.json convention: no leading slash, no .mdx extension.
+# ---------------------------------------------------------------------------
+PATH_MAPPING: dict[str, str] = {
+ # === Solutions (96 changed) ===
+ "embedded-wallets/overview": "solutions/embedded-wallets/overview",
+ "embedded-wallets/code-examples/embedded-consumer-wallet": "solutions/embedded-wallets/embedded-consumer-wallet",
+ "products/embedded-business-wallets/overview": "solutions/embedded-wallets/embedded-business-wallets",
+ "embedded-wallets/embedded-waas": "solutions/embedded-wallets/embedded-waas",
+ "getting-started/embedded-wallet-quickstart": "solutions/embedded-wallets/quickstart",
+ "embedded-wallets/integration-guide/overview": "solutions/embedded-wallets/integration-guide/overview",
+ # React (13)
+ "sdks/react/index": "solutions/embedded-wallets/integration-guide/react/index",
+ "sdks/react/getting-started": "solutions/embedded-wallets/integration-guide/react/getting-started",
+ "sdks/react/auth": "solutions/embedded-wallets/integration-guide/react/auth",
+ "sdks/react/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/react/using-embedded-wallets",
+ "sdks/react/using-external-wallets/overview": "solutions/embedded-wallets/integration-guide/react/using-external-wallets/overview",
+ "sdks/react/using-external-wallets/authentication": "solutions/embedded-wallets/integration-guide/react/using-external-wallets/authentication",
+ "sdks/react/using-external-wallets/connecting": "solutions/embedded-wallets/integration-guide/react/using-external-wallets/connecting",
+ "sdks/react/signing": "solutions/embedded-wallets/integration-guide/react/signing",
+ "sdks/react/ui-customization": "solutions/embedded-wallets/integration-guide/react/ui-customization",
+ "sdks/react/sub-organization-customization": "solutions/embedded-wallets/integration-guide/react/sub-organization-customization",
+ "sdks/react/advanced-api-requests": "solutions/embedded-wallets/integration-guide/react/advanced-api-requests",
+ "sdks/react/advanced-backend-authentication": "solutions/embedded-wallets/integration-guide/react/advanced-backend-authentication",
+ "sdks/react/migrating-sdk-react": "solutions/embedded-wallets/integration-guide/react/migrating-sdk-react",
+ "sdks/react/troubleshooting": "solutions/embedded-wallets/integration-guide/react/troubleshooting",
+ "sdks/react/legacy": "solutions/embedded-wallets/integration-guide/react/legacy",
+ # React Native (10)
+ "sdks/react-native/overview": "solutions/embedded-wallets/integration-guide/react-native/overview",
+ "sdks/react-native/getting-started": "solutions/embedded-wallets/integration-guide/react-native/getting-started",
+ "sdks/react-native/authentication/overview": "solutions/embedded-wallets/integration-guide/react-native/authentication/overview",
+ "sdks/react-native/authentication/email-sms": "solutions/embedded-wallets/integration-guide/react-native/authentication/email-sms",
+ "sdks/react-native/authentication/passkey": "solutions/embedded-wallets/integration-guide/react-native/authentication/passkey",
+ "sdks/react-native/authentication/social-logins": "solutions/embedded-wallets/integration-guide/react-native/authentication/social-logins",
+ "sdks/react-native/sub-organization-customization": "solutions/embedded-wallets/integration-guide/react-native/sub-organization-customization",
+ "sdks/react-native/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/react-native/using-embedded-wallets",
+ "sdks/react-native/signing": "solutions/embedded-wallets/integration-guide/react-native/signing",
+ "sdks/react-native/advanced-api-requests": "solutions/embedded-wallets/integration-guide/react-native/advanced-api-requests",
+ # TypeScript (6)
+ "sdks/typescript-frontend/index": "solutions/embedded-wallets/integration-guide/typescript/index",
+ "sdks/typescript-frontend/getting-started": "solutions/embedded-wallets/integration-guide/typescript/getting-started",
+ "sdks/typescript-frontend/auth": "solutions/embedded-wallets/integration-guide/typescript/auth",
+ "sdks/typescript-frontend/advanced-backend-authentication": "solutions/embedded-wallets/integration-guide/typescript/advanced-backend-authentication",
+ "sdks/typescript-frontend/advanced-api-requests": "solutions/embedded-wallets/integration-guide/typescript/advanced-api-requests",
+ "sdks/typescript-frontend/legacy": "solutions/embedded-wallets/integration-guide/typescript/legacy",
+ # Flutter (10)
+ "sdks/flutter/index": "solutions/embedded-wallets/integration-guide/flutter/index",
+ "sdks/flutter/getting-started": "solutions/embedded-wallets/integration-guide/flutter/getting-started",
+ "sdks/flutter/authentication/overview": "solutions/embedded-wallets/integration-guide/flutter/authentication/overview",
+ "sdks/flutter/authentication/email-sms": "solutions/embedded-wallets/integration-guide/flutter/authentication/email-sms",
+ "sdks/flutter/authentication/passkey": "solutions/embedded-wallets/integration-guide/flutter/authentication/passkey",
+ "sdks/flutter/authentication/social-logins": "solutions/embedded-wallets/integration-guide/flutter/authentication/social-logins",
+ "sdks/flutter/sub-organization-customization": "solutions/embedded-wallets/integration-guide/flutter/sub-organization-customization",
+ "sdks/flutter/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/flutter/using-embedded-wallets",
+ "sdks/flutter/signing": "solutions/embedded-wallets/integration-guide/flutter/signing",
+ "sdks/flutter/advanced-api-requests": "solutions/embedded-wallets/integration-guide/flutter/advanced-api-requests",
+ # Swift (11)
+ "sdks/swift/overview": "solutions/embedded-wallets/integration-guide/swift/overview",
+ "sdks/swift/getting-started": "solutions/embedded-wallets/integration-guide/swift/getting-started",
+ "sdks/swift/authentication/overview": "solutions/embedded-wallets/integration-guide/swift/authentication/overview",
+ "sdks/swift/authentication/email-sms": "solutions/embedded-wallets/integration-guide/swift/authentication/email-sms",
+ "sdks/swift/authentication/passkey": "solutions/embedded-wallets/integration-guide/swift/authentication/passkey",
+ "sdks/swift/authentication/social-logins": "solutions/embedded-wallets/integration-guide/swift/authentication/social-logins",
+ "sdks/swift/signing": "solutions/embedded-wallets/integration-guide/swift/signing",
+ "sdks/swift/sub-organization-customization": "solutions/embedded-wallets/integration-guide/swift/sub-organization-customization",
+ "sdks/swift/advanced-api-requests": "solutions/embedded-wallets/integration-guide/swift/advanced-api-requests",
+ "sdks/swift/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/swift/using-embedded-wallets",
+ "sdks/swift/advanced-backend-authentication": "solutions/embedded-wallets/integration-guide/swift/advanced-backend-authentication",
+ # Kotlin (11)
+ "sdks/kotlin/overview": "solutions/embedded-wallets/integration-guide/kotlin/overview",
+ "sdks/kotlin/getting-started": "solutions/embedded-wallets/integration-guide/kotlin/getting-started",
+ "sdks/kotlin/authentication/overview": "solutions/embedded-wallets/integration-guide/kotlin/authentication/overview",
+ "sdks/kotlin/authentication/email-sms": "solutions/embedded-wallets/integration-guide/kotlin/authentication/email-sms",
+ "sdks/kotlin/authentication/passkey": "solutions/embedded-wallets/integration-guide/kotlin/authentication/passkey",
+ "sdks/kotlin/authentication/social-logins": "solutions/embedded-wallets/integration-guide/kotlin/authentication/social-logins",
+ "sdks/kotlin/authentication/rp-id-setup": "solutions/embedded-wallets/integration-guide/kotlin/authentication/rp-id-setup",
+ "sdks/kotlin/sub-organization-customization": "solutions/embedded-wallets/integration-guide/kotlin/sub-organization-customization",
+ "sdks/kotlin/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/kotlin/using-embedded-wallets",
+ "sdks/kotlin/signing": "solutions/embedded-wallets/integration-guide/kotlin/signing",
+ "sdks/kotlin/advanced-api-requests": "solutions/embedded-wallets/integration-guide/kotlin/advanced-api-requests",
+ # Company Wallets (10)
+ "company-wallets/overview": "solutions/company-wallets/overview",
+ "company-wallets/code-examples/payment-orchestration": "solutions/company-wallets/payment-orchestration",
+ "company-wallets/code-examples/smart-contract-management": "solutions/company-wallets/smart-contract-management",
+ "company-wallets/use-cases/agentic-wallets": "solutions/company-wallets/agentic-wallets",
+ "getting-started/company-wallets-quickstart": "solutions/company-wallets/quickstart",
+ "company-wallets/integration-guide/overview": "solutions/company-wallets/integration-guide/overview",
+ "sdks/javascript-server": "solutions/company-wallets/integration-guide/javascript-server",
+ "sdks/golang": "solutions/company-wallets/integration-guide/golang",
+ "sdks/ruby": "solutions/company-wallets/integration-guide/ruby",
+ "sdks/rust": "solutions/company-wallets/integration-guide/rust",
+ "sdks/python": "solutions/company-wallets/integration-guide/python",
+ # Key Management (3)
+ "products/key-management/overview": "solutions/key-management/overview",
+ "products/key-management/examples/encryption-key-storage": "solutions/key-management/encryption-key-storage",
+ "products/key-management/examples/enterprise-disaster-recovery": "solutions/key-management/enterprise-disaster-recovery",
+ # Cookbooks (14)
+ "cookbook/landing": "solutions/cookbooks/landing",
+ "cookbook/morpho": "solutions/cookbooks/morpho",
+ "cookbook/aave": "solutions/cookbooks/aave",
+ "cookbook/breeze": "solutions/cookbooks/breeze",
+ "cookbook/yieldxyz": "solutions/cookbooks/yieldxyz",
+ "cookbook/jupiter": "solutions/cookbooks/jupiter",
+ "cookbook/lifi": "solutions/cookbooks/lifi",
+ "cookbook/0x": "solutions/cookbooks/0x",
+ "cookbook/relay": "solutions/cookbooks/relay",
+ "cookbook/polymarket-builders": "solutions/cookbooks/polymarket-builders",
+ "cookbook/base-builder-codes": "solutions/cookbooks/base-builder-codes",
+ "cookbook/brale": "solutions/cookbooks/brale",
+ "reference/tron-gasless-transactions": "solutions/cookbooks/tron-gasless-transactions",
+
+ # === Get started (7 changed) ===
+ "home": "get-started/about-turnkey",
+ "getting-started/quickstart": "get-started/quickstart",
+ "developer-reference/using-llms": "get-started/using-llms",
+ "ai/skills": "get-started/ai-skills",
+ "getting-started/examples": "get-started/examples",
+ "production-checklist/production-checklist": "get-started/production-checklist",
+ "production-checklist/backup-recovery": "get-started/backup-recovery",
+
+ # === Features (71 changed) ===
+ # Organizations (2)
+ "concepts/organizations": "features/organizations",
+ "concepts/sub-organizations": "features/sub-organizations",
+ # Users (4)
+ "concepts/users/introduction": "features/users/introduction",
+ "concepts/users/credentials": "features/users/credentials",
+ "concepts/users/root-quorum": "features/users/root-quorum",
+ "concepts/users/best-practices": "features/users/best-practices",
+ # Authentication (14)
+ "authentication/overview": "features/authentication/overview",
+ "authentication/email": "features/authentication/email",
+ "authentication/social-logins": "features/authentication/social-logins",
+ "authentication/sms": "features/authentication/sms",
+ "authentication/passkeys/introduction": "features/authentication/passkeys/introduction",
+ "authentication/passkeys/integration": "features/authentication/passkeys/integration",
+ "authentication/passkeys/options": "features/authentication/passkeys/options",
+ "authentication/passkeys/native": "features/authentication/passkeys/native",
+ "authentication/passkeys/discoverable-vs-non-discoverable": "features/authentication/passkeys/discoverable-vs-non-discoverable",
+ "authentication/backend-setup": "features/authentication/backend-setup",
+ "authentication/bring-your-own-auth": "features/authentication/bring-your-own-auth",
+ "reference/auth-proxy": "features/authentication/auth-proxy",
+ "authentication/sessions": "features/authentication/sessions",
+ "authentication/proxying-signed-requests": "features/authentication/proxying-signed-requests",
+ # Wallet and key management (7)
+ "concepts/wallets": "features/wallets",
+ "products/company-wallets/features/import-wallets": "features/wallets/import-wallets",
+ "products/company-wallets/features/export-wallets": "features/wallets/export-wallets",
+ "wallets/pregenerated-wallets": "features/wallets/pregenerated-wallets",
+ "wallets/claim-links": "features/wallets/claim-links",
+ "embedded-wallets/send-crypto-via-url": "features/wallets/send-crypto-via-url",
+ "reference/aa-wallets": "features/wallets/aa-wallets",
+ # Chain support / Networks (19)
+ "networks/overview": "features/networks/overview",
+ "networks/ethereum": "features/networks/ethereum",
+ "networks/solana": "features/networks/solana",
+ "networks/solana-transaction-construction": "features/networks/solana-transaction-construction",
+ "networks/solana-rent-refunds": "features/networks/solana-rent-refunds",
+ "networks/bitcoin": "features/networks/bitcoin",
+ "networks/spark": "features/networks/spark",
+ "networks/hyperliquid": "features/networks/hyperliquid",
+ "networks/cosmos": "features/networks/cosmos",
+ "networks/tron": "features/networks/tron",
+ "networks/sui": "features/networks/sui",
+ "networks/sei": "features/networks/sei",
+ "networks/stacks": "features/networks/stacks",
+ "networks/aptos": "features/networks/aptos",
+ "networks/tempo": "features/networks/tempo",
+ "networks/movement": "features/networks/movement",
+ "networks/iota": "features/networks/iota",
+ "networks/doge": "features/networks/doge",
+ "networks/others": "features/networks/others",
+ # Policies (13)
+ "concepts/policies/overview": "features/policies/overview",
+ "concepts/policies/quickstart": "features/policies/quickstart",
+ "concepts/policies/language": "features/policies/language",
+ "concepts/policies/smart-contract-interfaces": "features/policies/smart-contract-interfaces",
+ "concepts/policies/examples/access-control": "features/policies/examples/access-control",
+ "company-wallets/co-signing-transactions": "features/policies/examples/co-signing-transactions",
+ "concepts/policies/examples/signing-control": "features/policies/examples/signing-control",
+ "concepts/policies/examples/ethereum": "features/policies/examples/ethereum",
+ "concepts/policies/examples/solana": "features/policies/examples/solana",
+ "concepts/policies/examples/tron": "features/policies/examples/tron",
+ "concepts/policies/examples/bitcoin": "features/policies/examples/bitcoin",
+ "concepts/policies/examples/tempo": "features/policies/examples/tempo",
+ # Delegated access (4)
+ "concepts/policies/delegated-access-overview": "features/policies/delegated-access/overview",
+ "concepts/policies/delegated-access-frontend": "features/policies/delegated-access/frontend",
+ "concepts/policies/delegated-access-backend": "features/policies/delegated-access/backend",
+ "products/embedded-wallets/features/agentic-wallets": "features/policies/delegated-access/agentic-wallets",
+ # Transaction management (5)
+ "concepts/transaction-management": "features/transaction-management",
+ "concepts/broadcasting": "features/transaction-management/broadcasting",
+ "embedded-wallets/code-examples/sending-sponsored-transactions": "features/transaction-management/sending-sponsored-transactions",
+ "embedded-wallets/code-examples/sending-sponsored-solana-transactions": "features/transaction-management/sending-sponsored-solana-transactions",
+ "concepts/balances": "features/transaction-management/balances",
+ "wallets/fiat-on-ramp": "features/transaction-management/fiat-on-ramp",
+ # Verifiable Cloud (3)
+ "products/verifiable-cloud/overview": "features/verifiable-cloud/overview",
+ "products/verifiable-cloud/onboarding": "features/verifiable-cloud/onboarding",
+ "getting-started/verifiable-cloud-quickstart": "features/verifiable-cloud/quickstart",
+
+ # === Reference (4 changed) ===
+ "concepts/resource-limits": "reference/resource-limits",
+ "developer-reference/webhooks": "reference/webhooks",
+ "getting-started/migration-guide": "reference/migration-guide",
+ "faq": "reference/faq",
+
+ # === API reference (3 changed) ===
+ "developer-reference/api-overview/intro": "api-reference/overview/intro",
+ "developer-reference/api-overview/stamps": "api-reference/overview/stamps",
+ "developer-reference/api-overview/errors": "api-reference/overview/errors",
+
+ # === SDK reference (4 changed) ===
+ "category/web3-libraries": "sdks/web3/overview",
+ "wallets/wagmi": "sdks/web3/wagmi",
+ "category/advanced": "sdks/advanced/overview",
+ "embedded-wallets/code-examples/client-side-signing": "sdks/advanced/client-side-signing",
+
+ # === Security (2 changed) ===
+ "category/security": "security/overview",
+ "products/company-wallets/features/security/remote-attestation": "security/remote-attestation",
+}
+
+EXPECTED_COUNT = 187
+
+DOCS_JSON_PATH = Path(__file__).resolve().parent / "docs.json"
+
+
+def walk_and_replace(node, mapping: dict[str, str]) -> int:
+ """
+ Recursively walk a JSON structure (the navigation section).
+ For every string found inside a "pages" array, check if it matches
+ an old path in the mapping. If so, replace it with the new path.
+
+ Returns the total number of replacements made.
+ """
+ replacements = 0
+
+ if isinstance(node, dict):
+ for key, value in node.items():
+ if key == "pages" and isinstance(value, list):
+ # Walk the pages array
+ for i, item in enumerate(value):
+ if isinstance(item, str):
+ if item in mapping:
+ node[key][i] = mapping[item]
+ replacements += 1
+ elif isinstance(item, dict):
+ replacements += walk_and_replace(item, mapping)
+ else:
+ replacements += walk_and_replace(value, mapping)
+ elif isinstance(node, list):
+ for item in node:
+ replacements += walk_and_replace(item, mapping)
+
+ return replacements
+
+
+def main() -> None:
+ # --- Verify mapping count ---
+ actual_count = len(PATH_MAPPING)
+ if actual_count != EXPECTED_COUNT:
+ print(
+ f"ERROR: Expected {EXPECTED_COUNT} entries in PATH_MAPPING, "
+ f"but found {actual_count}.",
+ file=sys.stderr,
+ )
+ sys.exit(1)
+ print(f"Mapping contains {actual_count} entries (verified).")
+
+ # --- Read docs.json ---
+ if not DOCS_JSON_PATH.exists():
+ print(f"ERROR: {DOCS_JSON_PATH} not found.", file=sys.stderr)
+ sys.exit(1)
+
+ with open(DOCS_JSON_PATH, "r", encoding="utf-8") as f:
+ data = json.load(f)
+
+ # --- Extract and process only the navigation section ---
+ if "navigation" not in data:
+ print("ERROR: No 'navigation' key found in docs.json.", file=sys.stderr)
+ sys.exit(1)
+
+ # Track which old paths we actually replaced (to find missing ones later)
+ tracking_mapping = dict(PATH_MAPPING) # copy we can pop from
+
+ navigation = data["navigation"]
+ replacements = walk_and_replace(navigation, PATH_MAPPING)
+
+ # --- Figure out which old paths were NOT found in navigation ---
+ # Re-walk the updated navigation to collect all page strings
+ def collect_all_pages(node: object) -> set[str]:
+ pages: set[str] = set()
+ if isinstance(node, dict):
+ for key, value in node.items():
+ if key == "pages" and isinstance(value, list):
+ for item in value:
+ if isinstance(item, str):
+ pages.add(item)
+ elif isinstance(item, dict):
+ pages.update(collect_all_pages(item))
+ else:
+ pages.update(collect_all_pages(value))
+ elif isinstance(node, list):
+ for item in node:
+ pages.update(collect_all_pages(item))
+ return pages
+
+ all_new_pages = collect_all_pages(navigation)
+
+ # An old path is "not found" if its NEW value does not appear in the
+ # final navigation (meaning the old path was never encountered).
+ not_found: list[str] = []
+ for old_path, new_path in PATH_MAPPING.items():
+ if new_path not in all_new_pages:
+ not_found.append(old_path)
+
+ # --- Write back ---
+ with open(DOCS_JSON_PATH, "w", encoding="utf-8") as f:
+ json.dump(data, f, indent=2, ensure_ascii=False)
+ f.write("\n") # trailing newline
+
+ # --- Summary ---
+ print(f"Replacements made: {replacements}")
+ print(f"Old paths NOT found in docs.json navigation: {len(not_found)}")
+ if not_found:
+ print("\nWARNING: The following old paths were not found in navigation:")
+ for p in sorted(not_found):
+ print(f" - {p}")
+ else:
+ print("All old paths were found and replaced successfully.")
+
+
+if __name__ == "__main__":
+ main()
diff --git a/step3-add-nav-redirects.py b/step3-add-nav-redirects.py
new file mode 100644
index 00000000..f66b9dc6
--- /dev/null
+++ b/step3-add-nav-redirects.py
@@ -0,0 +1,360 @@
+#!/usr/bin/env python3
+"""
+Step 3: Add redirect entries to docs.json for the 187 moved nav pages.
+
+This script reads docs.json, finds the existing "redirects" array, and
+APPENDS 187 new redirect entries corresponding to the Phase 3 URL mapping.
+Existing redirects are left untouched.
+
+Each new redirect entry has the form:
+ {
+ "source": "/OLD_PATH",
+ "destination": "/NEW_PATH",
+ "permanent": true
+ }
+
+Usage:
+ python step3-add-nav-redirects.py
+"""
+
+import json
+import sys
+from pathlib import Path
+
+# ---------------------------------------------------------------------------
+# Phase 3 mapping: old path -> new path (only rows where Changed = Yes)
+# Same 187 entries used by step2-update-docsjson.py.
+# Paths here are bare (no leading slash, no .mdx). The script will add
+# a leading "/" when building redirect source/destination values.
+# ---------------------------------------------------------------------------
+PATH_MAPPING: dict[str, str] = {
+ # === Solutions (96 changed) ===
+ "embedded-wallets/overview": "solutions/embedded-wallets/overview",
+ "embedded-wallets/code-examples/embedded-consumer-wallet": "solutions/embedded-wallets/embedded-consumer-wallet",
+ "products/embedded-business-wallets/overview": "solutions/embedded-wallets/embedded-business-wallets",
+ "embedded-wallets/embedded-waas": "solutions/embedded-wallets/embedded-waas",
+ "getting-started/embedded-wallet-quickstart": "solutions/embedded-wallets/quickstart",
+ "embedded-wallets/integration-guide/overview": "solutions/embedded-wallets/integration-guide/overview",
+ # React (13)
+ "sdks/react/index": "solutions/embedded-wallets/integration-guide/react/index",
+ "sdks/react/getting-started": "solutions/embedded-wallets/integration-guide/react/getting-started",
+ "sdks/react/auth": "solutions/embedded-wallets/integration-guide/react/auth",
+ "sdks/react/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/react/using-embedded-wallets",
+ "sdks/react/using-external-wallets/overview": "solutions/embedded-wallets/integration-guide/react/using-external-wallets/overview",
+ "sdks/react/using-external-wallets/authentication": "solutions/embedded-wallets/integration-guide/react/using-external-wallets/authentication",
+ "sdks/react/using-external-wallets/connecting": "solutions/embedded-wallets/integration-guide/react/using-external-wallets/connecting",
+ "sdks/react/signing": "solutions/embedded-wallets/integration-guide/react/signing",
+ "sdks/react/ui-customization": "solutions/embedded-wallets/integration-guide/react/ui-customization",
+ "sdks/react/sub-organization-customization": "solutions/embedded-wallets/integration-guide/react/sub-organization-customization",
+ "sdks/react/advanced-api-requests": "solutions/embedded-wallets/integration-guide/react/advanced-api-requests",
+ "sdks/react/advanced-backend-authentication": "solutions/embedded-wallets/integration-guide/react/advanced-backend-authentication",
+ "sdks/react/migrating-sdk-react": "solutions/embedded-wallets/integration-guide/react/migrating-sdk-react",
+ "sdks/react/troubleshooting": "solutions/embedded-wallets/integration-guide/react/troubleshooting",
+ "sdks/react/legacy": "solutions/embedded-wallets/integration-guide/react/legacy",
+ # React Native (10)
+ "sdks/react-native/overview": "solutions/embedded-wallets/integration-guide/react-native/overview",
+ "sdks/react-native/getting-started": "solutions/embedded-wallets/integration-guide/react-native/getting-started",
+ "sdks/react-native/authentication/overview": "solutions/embedded-wallets/integration-guide/react-native/authentication/overview",
+ "sdks/react-native/authentication/email-sms": "solutions/embedded-wallets/integration-guide/react-native/authentication/email-sms",
+ "sdks/react-native/authentication/passkey": "solutions/embedded-wallets/integration-guide/react-native/authentication/passkey",
+ "sdks/react-native/authentication/social-logins": "solutions/embedded-wallets/integration-guide/react-native/authentication/social-logins",
+ "sdks/react-native/sub-organization-customization": "solutions/embedded-wallets/integration-guide/react-native/sub-organization-customization",
+ "sdks/react-native/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/react-native/using-embedded-wallets",
+ "sdks/react-native/signing": "solutions/embedded-wallets/integration-guide/react-native/signing",
+ "sdks/react-native/advanced-api-requests": "solutions/embedded-wallets/integration-guide/react-native/advanced-api-requests",
+ # TypeScript (6)
+ "sdks/typescript-frontend/index": "solutions/embedded-wallets/integration-guide/typescript/index",
+ "sdks/typescript-frontend/getting-started": "solutions/embedded-wallets/integration-guide/typescript/getting-started",
+ "sdks/typescript-frontend/auth": "solutions/embedded-wallets/integration-guide/typescript/auth",
+ "sdks/typescript-frontend/advanced-backend-authentication": "solutions/embedded-wallets/integration-guide/typescript/advanced-backend-authentication",
+ "sdks/typescript-frontend/advanced-api-requests": "solutions/embedded-wallets/integration-guide/typescript/advanced-api-requests",
+ "sdks/typescript-frontend/legacy": "solutions/embedded-wallets/integration-guide/typescript/legacy",
+ # Flutter (10)
+ "sdks/flutter/index": "solutions/embedded-wallets/integration-guide/flutter/index",
+ "sdks/flutter/getting-started": "solutions/embedded-wallets/integration-guide/flutter/getting-started",
+ "sdks/flutter/authentication/overview": "solutions/embedded-wallets/integration-guide/flutter/authentication/overview",
+ "sdks/flutter/authentication/email-sms": "solutions/embedded-wallets/integration-guide/flutter/authentication/email-sms",
+ "sdks/flutter/authentication/passkey": "solutions/embedded-wallets/integration-guide/flutter/authentication/passkey",
+ "sdks/flutter/authentication/social-logins": "solutions/embedded-wallets/integration-guide/flutter/authentication/social-logins",
+ "sdks/flutter/sub-organization-customization": "solutions/embedded-wallets/integration-guide/flutter/sub-organization-customization",
+ "sdks/flutter/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/flutter/using-embedded-wallets",
+ "sdks/flutter/signing": "solutions/embedded-wallets/integration-guide/flutter/signing",
+ "sdks/flutter/advanced-api-requests": "solutions/embedded-wallets/integration-guide/flutter/advanced-api-requests",
+ # Swift (11)
+ "sdks/swift/overview": "solutions/embedded-wallets/integration-guide/swift/overview",
+ "sdks/swift/getting-started": "solutions/embedded-wallets/integration-guide/swift/getting-started",
+ "sdks/swift/authentication/overview": "solutions/embedded-wallets/integration-guide/swift/authentication/overview",
+ "sdks/swift/authentication/email-sms": "solutions/embedded-wallets/integration-guide/swift/authentication/email-sms",
+ "sdks/swift/authentication/passkey": "solutions/embedded-wallets/integration-guide/swift/authentication/passkey",
+ "sdks/swift/authentication/social-logins": "solutions/embedded-wallets/integration-guide/swift/authentication/social-logins",
+ "sdks/swift/signing": "solutions/embedded-wallets/integration-guide/swift/signing",
+ "sdks/swift/sub-organization-customization": "solutions/embedded-wallets/integration-guide/swift/sub-organization-customization",
+ "sdks/swift/advanced-api-requests": "solutions/embedded-wallets/integration-guide/swift/advanced-api-requests",
+ "sdks/swift/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/swift/using-embedded-wallets",
+ "sdks/swift/advanced-backend-authentication": "solutions/embedded-wallets/integration-guide/swift/advanced-backend-authentication",
+ # Kotlin (11)
+ "sdks/kotlin/overview": "solutions/embedded-wallets/integration-guide/kotlin/overview",
+ "sdks/kotlin/getting-started": "solutions/embedded-wallets/integration-guide/kotlin/getting-started",
+ "sdks/kotlin/authentication/overview": "solutions/embedded-wallets/integration-guide/kotlin/authentication/overview",
+ "sdks/kotlin/authentication/email-sms": "solutions/embedded-wallets/integration-guide/kotlin/authentication/email-sms",
+ "sdks/kotlin/authentication/passkey": "solutions/embedded-wallets/integration-guide/kotlin/authentication/passkey",
+ "sdks/kotlin/authentication/social-logins": "solutions/embedded-wallets/integration-guide/kotlin/authentication/social-logins",
+ "sdks/kotlin/authentication/rp-id-setup": "solutions/embedded-wallets/integration-guide/kotlin/authentication/rp-id-setup",
+ "sdks/kotlin/sub-organization-customization": "solutions/embedded-wallets/integration-guide/kotlin/sub-organization-customization",
+ "sdks/kotlin/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/kotlin/using-embedded-wallets",
+ "sdks/kotlin/signing": "solutions/embedded-wallets/integration-guide/kotlin/signing",
+ "sdks/kotlin/advanced-api-requests": "solutions/embedded-wallets/integration-guide/kotlin/advanced-api-requests",
+ # Company Wallets (10)
+ "company-wallets/overview": "solutions/company-wallets/overview",
+ "company-wallets/code-examples/payment-orchestration": "solutions/company-wallets/payment-orchestration",
+ "company-wallets/code-examples/smart-contract-management": "solutions/company-wallets/smart-contract-management",
+ "company-wallets/use-cases/agentic-wallets": "solutions/company-wallets/agentic-wallets",
+ "getting-started/company-wallets-quickstart": "solutions/company-wallets/quickstart",
+ "company-wallets/integration-guide/overview": "solutions/company-wallets/integration-guide/overview",
+ "sdks/javascript-server": "solutions/company-wallets/integration-guide/javascript-server",
+ "sdks/golang": "solutions/company-wallets/integration-guide/golang",
+ "sdks/ruby": "solutions/company-wallets/integration-guide/ruby",
+ "sdks/rust": "solutions/company-wallets/integration-guide/rust",
+ "sdks/python": "solutions/company-wallets/integration-guide/python",
+ # Key Management (3)
+ "products/key-management/overview": "solutions/key-management/overview",
+ "products/key-management/examples/encryption-key-storage": "solutions/key-management/encryption-key-storage",
+ "products/key-management/examples/enterprise-disaster-recovery": "solutions/key-management/enterprise-disaster-recovery",
+ # Cookbooks (14)
+ "cookbook/landing": "solutions/cookbooks/landing",
+ "cookbook/morpho": "solutions/cookbooks/morpho",
+ "cookbook/aave": "solutions/cookbooks/aave",
+ "cookbook/breeze": "solutions/cookbooks/breeze",
+ "cookbook/yieldxyz": "solutions/cookbooks/yieldxyz",
+ "cookbook/jupiter": "solutions/cookbooks/jupiter",
+ "cookbook/lifi": "solutions/cookbooks/lifi",
+ "cookbook/0x": "solutions/cookbooks/0x",
+ "cookbook/relay": "solutions/cookbooks/relay",
+ "cookbook/polymarket-builders": "solutions/cookbooks/polymarket-builders",
+ "cookbook/base-builder-codes": "solutions/cookbooks/base-builder-codes",
+ "cookbook/brale": "solutions/cookbooks/brale",
+ "reference/tron-gasless-transactions": "solutions/cookbooks/tron-gasless-transactions",
+
+ # === Get started (7 changed) ===
+ "home": "get-started/about-turnkey",
+ "getting-started/quickstart": "get-started/quickstart",
+ "developer-reference/using-llms": "get-started/using-llms",
+ "ai/skills": "get-started/ai-skills",
+ "getting-started/examples": "get-started/examples",
+ "production-checklist/production-checklist": "get-started/production-checklist",
+ "production-checklist/backup-recovery": "get-started/backup-recovery",
+
+ # === Features (71 changed) ===
+ # Organizations (2)
+ "concepts/organizations": "features/organizations",
+ "concepts/sub-organizations": "features/sub-organizations",
+ # Users (4)
+ "concepts/users/introduction": "features/users/introduction",
+ "concepts/users/credentials": "features/users/credentials",
+ "concepts/users/root-quorum": "features/users/root-quorum",
+ "concepts/users/best-practices": "features/users/best-practices",
+ # Authentication (14)
+ "authentication/overview": "features/authentication/overview",
+ "authentication/email": "features/authentication/email",
+ "authentication/social-logins": "features/authentication/social-logins",
+ "authentication/sms": "features/authentication/sms",
+ "authentication/passkeys/introduction": "features/authentication/passkeys/introduction",
+ "authentication/passkeys/integration": "features/authentication/passkeys/integration",
+ "authentication/passkeys/options": "features/authentication/passkeys/options",
+ "authentication/passkeys/native": "features/authentication/passkeys/native",
+ "authentication/passkeys/discoverable-vs-non-discoverable": "features/authentication/passkeys/discoverable-vs-non-discoverable",
+ "authentication/backend-setup": "features/authentication/backend-setup",
+ "authentication/bring-your-own-auth": "features/authentication/bring-your-own-auth",
+ "reference/auth-proxy": "features/authentication/auth-proxy",
+ "authentication/sessions": "features/authentication/sessions",
+ "authentication/proxying-signed-requests": "features/authentication/proxying-signed-requests",
+ # Wallet and key management (7)
+ "concepts/wallets": "features/wallets",
+ "products/company-wallets/features/import-wallets": "features/wallets/import-wallets",
+ "products/company-wallets/features/export-wallets": "features/wallets/export-wallets",
+ "wallets/pregenerated-wallets": "features/wallets/pregenerated-wallets",
+ "wallets/claim-links": "features/wallets/claim-links",
+ "embedded-wallets/send-crypto-via-url": "features/wallets/send-crypto-via-url",
+ "reference/aa-wallets": "features/wallets/aa-wallets",
+ # Chain support / Networks (19)
+ "networks/overview": "features/networks/overview",
+ "networks/ethereum": "features/networks/ethereum",
+ "networks/solana": "features/networks/solana",
+ "networks/solana-transaction-construction": "features/networks/solana-transaction-construction",
+ "networks/solana-rent-refunds": "features/networks/solana-rent-refunds",
+ "networks/bitcoin": "features/networks/bitcoin",
+ "networks/spark": "features/networks/spark",
+ "networks/hyperliquid": "features/networks/hyperliquid",
+ "networks/cosmos": "features/networks/cosmos",
+ "networks/tron": "features/networks/tron",
+ "networks/sui": "features/networks/sui",
+ "networks/sei": "features/networks/sei",
+ "networks/stacks": "features/networks/stacks",
+ "networks/aptos": "features/networks/aptos",
+ "networks/tempo": "features/networks/tempo",
+ "networks/movement": "features/networks/movement",
+ "networks/iota": "features/networks/iota",
+ "networks/doge": "features/networks/doge",
+ "networks/others": "features/networks/others",
+ # Policies (13)
+ "concepts/policies/overview": "features/policies/overview",
+ "concepts/policies/quickstart": "features/policies/quickstart",
+ "concepts/policies/language": "features/policies/language",
+ "concepts/policies/smart-contract-interfaces": "features/policies/smart-contract-interfaces",
+ "concepts/policies/examples/access-control": "features/policies/examples/access-control",
+ "company-wallets/co-signing-transactions": "features/policies/examples/co-signing-transactions",
+ "concepts/policies/examples/signing-control": "features/policies/examples/signing-control",
+ "concepts/policies/examples/ethereum": "features/policies/examples/ethereum",
+ "concepts/policies/examples/solana": "features/policies/examples/solana",
+ "concepts/policies/examples/tron": "features/policies/examples/tron",
+ "concepts/policies/examples/bitcoin": "features/policies/examples/bitcoin",
+ "concepts/policies/examples/tempo": "features/policies/examples/tempo",
+ # Delegated access (4)
+ "concepts/policies/delegated-access-overview": "features/policies/delegated-access/overview",
+ "concepts/policies/delegated-access-frontend": "features/policies/delegated-access/frontend",
+ "concepts/policies/delegated-access-backend": "features/policies/delegated-access/backend",
+ "products/embedded-wallets/features/agentic-wallets": "features/policies/delegated-access/agentic-wallets",
+ # Transaction management (5)
+ "concepts/transaction-management": "features/transaction-management",
+ "concepts/broadcasting": "features/transaction-management/broadcasting",
+ "embedded-wallets/code-examples/sending-sponsored-transactions": "features/transaction-management/sending-sponsored-transactions",
+ "embedded-wallets/code-examples/sending-sponsored-solana-transactions": "features/transaction-management/sending-sponsored-solana-transactions",
+ "concepts/balances": "features/transaction-management/balances",
+ "wallets/fiat-on-ramp": "features/transaction-management/fiat-on-ramp",
+ # Verifiable Cloud (3)
+ "products/verifiable-cloud/overview": "features/verifiable-cloud/overview",
+ "products/verifiable-cloud/onboarding": "features/verifiable-cloud/onboarding",
+ "getting-started/verifiable-cloud-quickstart": "features/verifiable-cloud/quickstart",
+
+ # === Reference (4 changed) ===
+ "concepts/resource-limits": "reference/resource-limits",
+ "developer-reference/webhooks": "reference/webhooks",
+ "getting-started/migration-guide": "reference/migration-guide",
+ "faq": "reference/faq",
+
+ # === API reference (3 changed) ===
+ "developer-reference/api-overview/intro": "api-reference/overview/intro",
+ "developer-reference/api-overview/stamps": "api-reference/overview/stamps",
+ "developer-reference/api-overview/errors": "api-reference/overview/errors",
+
+ # === SDK reference (4 changed) ===
+ "category/web3-libraries": "sdks/web3/overview",
+ "wallets/wagmi": "sdks/web3/wagmi",
+ "category/advanced": "sdks/advanced/overview",
+ "embedded-wallets/code-examples/client-side-signing": "sdks/advanced/client-side-signing",
+
+ # === Security (2 changed) ===
+ "category/security": "security/overview",
+ "products/company-wallets/features/security/remote-attestation": "security/remote-attestation",
+}
+
+EXPECTED_COUNT = 187
+
+DOCS_JSON_PATH = Path(__file__).resolve().parent / "docs.json"
+
+
+def main() -> None:
+ # --- Verify mapping count ---
+ actual_count = len(PATH_MAPPING)
+ if actual_count != EXPECTED_COUNT:
+ print(
+ f"ERROR: Expected {EXPECTED_COUNT} entries in PATH_MAPPING, "
+ f"but found {actual_count}.",
+ file=sys.stderr,
+ )
+ sys.exit(1)
+ print(f"Mapping contains {actual_count} entries (verified).")
+
+ # --- Read docs.json ---
+ if not DOCS_JSON_PATH.exists():
+ print(f"ERROR: {DOCS_JSON_PATH} not found.", file=sys.stderr)
+ sys.exit(1)
+
+ with open(DOCS_JSON_PATH, "r", encoding="utf-8") as f:
+ data = json.load(f)
+
+ # --- Validate that "redirects" key exists and is a list ---
+ if "redirects" not in data:
+ print("ERROR: No 'redirects' key found in docs.json.", file=sys.stderr)
+ sys.exit(1)
+
+ if not isinstance(data["redirects"], list):
+ print("ERROR: 'redirects' is not an array in docs.json.", file=sys.stderr)
+ sys.exit(1)
+
+ existing_redirects = data["redirects"]
+ existing_count = len(existing_redirects)
+ print(f"Existing redirects: {existing_count}")
+
+ # --- Build a set of existing source paths to detect duplicates ---
+ existing_sources = set()
+ for r in existing_redirects:
+ if isinstance(r, dict) and "source" in r:
+ existing_sources.add(r["source"])
+
+ # --- Build new redirect entries ---
+ new_redirects: list[dict] = []
+ skipped_duplicates: list[str] = []
+
+ for old_path, new_path in PATH_MAPPING.items():
+ source = f"/{old_path}"
+ destination = f"/{new_path}"
+
+ # Skip if this source already exists in the redirects array
+ if source in existing_sources:
+ skipped_duplicates.append(source)
+ continue
+
+ new_redirects.append({
+ "source": source,
+ "destination": destination,
+ "permanent": True,
+ })
+
+ # --- Verify we are adding exactly 187 new redirects ---
+ new_count = len(new_redirects)
+ skipped_count = len(skipped_duplicates)
+
+ if skipped_count > 0:
+ print(f"\nWARNING: Skipped {skipped_count} duplicate source(s) already in redirects:")
+ for s in sorted(skipped_duplicates):
+ print(f" - {s}")
+ print()
+
+ total_new = new_count + skipped_count
+ if total_new != EXPECTED_COUNT:
+ print(
+ f"ERROR: Expected {EXPECTED_COUNT} redirect mappings, "
+ f"but found {new_count} new + {skipped_count} duplicates = {total_new}.",
+ file=sys.stderr,
+ )
+ sys.exit(1)
+
+ if new_count != EXPECTED_COUNT and skipped_count == 0:
+ print(
+ f"ERROR: Expected to add exactly {EXPECTED_COUNT} redirects, "
+ f"but built {new_count}.",
+ file=sys.stderr,
+ )
+ sys.exit(1)
+
+ # --- Append new redirects (do NOT modify existing ones) ---
+ data["redirects"].extend(new_redirects)
+
+ final_count = len(data["redirects"])
+
+ # --- Write back with 2-space indent ---
+ with open(DOCS_JSON_PATH, "w", encoding="utf-8") as f:
+ json.dump(data, f, indent=2, ensure_ascii=False)
+ f.write("\n") # trailing newline
+
+ # --- Summary ---
+ print(f"New redirects added: {new_count}")
+ print(f"Total redirects before: {existing_count}")
+ print(f"Total redirects after: {final_count}")
+ print(f"Net change: +{final_count - existing_count}")
+ print("\nDone. docs.json updated successfully.")
+
+
+if __name__ == "__main__":
+ main()
diff --git a/step4-add-orphan-redirects.py b/step4-add-orphan-redirects.py
new file mode 100644
index 00000000..f5da1eb7
--- /dev/null
+++ b/step4-add-orphan-redirects.py
@@ -0,0 +1,522 @@
+#!/usr/bin/env python3
+"""
+Step 4: Add redirect entries for orphaned pages.
+
+Adds 70 redirect entries to docs.json for pages that were removed from
+navigation (orphaned) during the docs restructure. Each orphan is redirected
+to the most relevant replacement page.
+
+These redirects were derived from the Phase 2 tables in url-mapping-draft.md,
+with destination paths resolved through the Phase 3 mapping to final URLs.
+
+Usage:
+ python3 step4-add-orphan-redirects.py
+"""
+
+import json
+import sys
+from pathlib import Path
+
+DOCS_JSON = Path(__file__).parent / "docs.json"
+
+# ---------------------------------------------------------------------------
+# 70 orphan redirect entries (source -> destination), fully resolved.
+#
+# Organized by category matching the Phase 2 tables:
+# - Product Features (14)
+# - API Pages (8)
+# - Code Examples (16)
+# - Overview/Landing Pages (7)
+# - Auth/Getting-Started/Misc (9)
+# - Production Checklists (2)
+# - SDK Pages (11)
+# - Wallet Pages (2)
+# - Additional (1)
+# ---------------------------------------------------------------------------
+
+ORPHAN_REDIRECTS = [
+ # ── Product Features (14) ─────────────────────────────────────────────
+ {
+ "source": "/products/company-wallets/features/dashboard",
+ "destination": "/solutions/company-wallets/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/products/company-wallets/features/multi-chain-support",
+ "destination": "/features/networks/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/products/company-wallets/features/off-chain-contracts",
+ "destination": "/solutions/company-wallets/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/products/company-wallets/features/scoped-api-key",
+ "destination": "/solutions/company-wallets/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/products/company-wallets/features/security/compliance",
+ "destination": "/security/our-approach",
+ "permanent": True,
+ },
+ {
+ "source": "/products/company-wallets/features/security/quorum-os",
+ "destination": "/security/secure-enclaves",
+ "permanent": True,
+ },
+ {
+ "source": "/products/company-wallets/features/security/secure-hardware",
+ "destination": "/security/secure-enclaves",
+ "permanent": True,
+ },
+ {
+ "source": "/products/company-wallets/policy-engine",
+ "destination": "/features/policies/quickstart",
+ "permanent": True,
+ },
+ {
+ "source": "/products/embedded-wallets/features/export-wallets",
+ "destination": "/features/wallets/export-wallets",
+ "permanent": True,
+ },
+ {
+ "source": "/products/embedded-wallets/features/fiat-on-ramp",
+ "destination": "/features/transaction-management/fiat-on-ramp",
+ "permanent": True,
+ },
+ {
+ "source": "/products/embedded-wallets/features/gas-sponsorship",
+ "destination": "/features/transaction-management/broadcasting",
+ "permanent": True,
+ },
+ {
+ "source": "/products/embedded-wallets/features/import-wallets",
+ "destination": "/features/wallets/import-wallets",
+ "permanent": True,
+ },
+ {
+ "source": "/products/embedded-wallets/features/multi-chain-support",
+ "destination": "/features/networks/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/products/embedded-wallets/features/policy-engine",
+ "destination": "/features/policies/quickstart",
+ "permanent": True,
+ },
+ # ── API Pages (8) ─────────────────────────────────────────────────────
+ {
+ "source": "/api-overview",
+ "destination": "/api-reference/overview/intro",
+ "permanent": True,
+ },
+ {
+ "source": "/api-reference/activities/submit-a-raw-transaction-for-broadcasting",
+ "destination": "/api-reference/activities/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/api-reference/activities/submit-a-transaction-intent-for-broadcasting",
+ "destination": "/api-reference/activities/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/api-reference/overview",
+ "destination": "/api-reference/overview/intro",
+ "permanent": True,
+ },
+ {
+ "source": "/api-reference/queries/get-gas-usage-and-limits",
+ "destination": "/api-reference/queries/get-gas-usage",
+ "permanent": True,
+ },
+ {
+ "source": "/api-reference/queries/get-nonces-for-an-address",
+ "destination": "/api-reference/queries/get-nonces",
+ "permanent": True,
+ },
+ {
+ "source": "/api-reference/queries/get-suborgs",
+ "destination": "/api-reference/queries/get-sub-organizations",
+ "permanent": True,
+ },
+ {
+ "source": "/api-reference/queries/get-verified-suborgs",
+ "destination": "/api-reference/queries/get-verified-sub-organizations",
+ "permanent": True,
+ },
+ # ── Code Examples (16) ────────────────────────────────────────────────
+ {
+ "source": "/company-wallets/code-examples/balance-sweeper",
+ "destination": "/solutions/company-wallets/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/company-wallets/code-examples/sending-sponsored-transactions",
+ "destination": "/features/transaction-management/broadcasting",
+ "permanent": True,
+ },
+ {
+ "source": "/company-wallets/code-examples/signing-transactions",
+ "destination": "/solutions/company-wallets/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/code-examples/add-credential",
+ "destination": "/solutions/embedded-wallets/integration-guide/react/index",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/code-examples/authenticate-user-email",
+ "destination": "/solutions/embedded-wallets/integration-guide/react/auth",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/code-examples/authenticate-user-passkey",
+ "destination": "/solutions/embedded-wallets/integration-guide/react/sub-organization-customization",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/code-examples/create-passkey-session",
+ "destination": "/solutions/embedded-wallets/integration-guide/react/auth",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/code-examples/create-sub-org-passkey",
+ "destination": "/solutions/embedded-wallets/integration-guide/react/sub-organization-customization",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/code-examples/create-user-email",
+ "destination": "/solutions/embedded-wallets/integration-guide/react/sub-organization-customization",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/code-examples/email-recovery",
+ "destination": "/features/authentication/email",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/code-examples/export",
+ "destination": "/solutions/embedded-wallets/integration-guide/react/using-embedded-wallets",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/code-examples/fiat-on-ramp",
+ "destination": "/features/transaction-management/fiat-on-ramp",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/code-examples/import",
+ "destination": "/solutions/embedded-wallets/integration-guide/react/using-embedded-wallets",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/code-examples/signing-transactions",
+ "destination": "/solutions/embedded-wallets/integration-guide/react/signing",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/code-examples/social-linking",
+ "destination": "/solutions/embedded-wallets/integration-guide/react/auth",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/code-examples/wallet-auth",
+ "destination": "/solutions/embedded-wallets/integration-guide/react/using-external-wallets/overview",
+ "permanent": True,
+ },
+ # ── Overview/Landing Pages (7) ────────────────────────────────────────
+ {
+ "source": "/category/code-examples",
+ "destination": "/solutions/embedded-wallets/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/category/code-examples-1",
+ "destination": "/solutions/company-wallets/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/concepts/overview",
+ "destination": "/get-started/about-turnkey",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/demos",
+ "destination": "/solutions/embedded-wallets/quickstart",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/features/overview",
+ "destination": "/solutions/embedded-wallets/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/products/key-management/examples/overview",
+ "destination": "/solutions/key-management/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/products/verifiable-cloud/lifecycle",
+ "destination": "/features/verifiable-cloud/overview",
+ "permanent": True,
+ },
+ # ── Auth/Getting-Started/Misc (9) ─────────────────────────────────────
+ {
+ "source": "/authentication/credentials",
+ "destination": "/features/users/credentials",
+ "permanent": True,
+ },
+ {
+ "source": "/authentication/otp-migration-guide",
+ "destination": "/features/authentication/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/cookbook/gelato",
+ "destination": "/sdks/web3/gas-station",
+ "permanent": True,
+ },
+ {
+ "source": "/developer-reference/api-overview/queries",
+ "destination": "/api-reference/queries/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/developer-reference/api-overview/submissions",
+ "destination": "/api-reference/activities/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/sub-organization-auth",
+ "destination": "/features/authentication/email",
+ "permanent": True,
+ },
+ {
+ "source": "/embedded-wallets/sub-organization-recovery",
+ "destination": "/features/authentication/email",
+ "permanent": True,
+ },
+ {
+ "source": "/getting-started",
+ "destination": "/get-started/about-turnkey",
+ "permanent": True,
+ },
+ {
+ "source": "/getting-started/launch-checklist",
+ "destination": "/get-started/production-checklist",
+ "permanent": True,
+ },
+ # ── Production Checklists (2) ─────────────────────────────────────────
+ {
+ "source": "/production-checklist/company-wallet",
+ "destination": "/solutions/company-wallets/integration-guide/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/production-checklist/embedded-wallet",
+ "destination": "/solutions/embedded-wallets/integration-guide/overview",
+ "permanent": True,
+ },
+ # ── SDK Pages (11) ────────────────────────────────────────────────────
+ {
+ "source": "/reference/embedded-wallet-kit",
+ "destination": "/solutions/embedded-wallets/integration-guide/react/getting-started",
+ "permanent": True,
+ },
+ {
+ "source": "/reference/solana-gasless-transactions",
+ "destination": "/features/transaction-management",
+ "permanent": True,
+ },
+ {
+ "source": "/sdks/cli",
+ "destination": "/sdks/introduction",
+ "permanent": True,
+ },
+ {
+ "source": "/sdks/flutter/landing",
+ "destination": "/solutions/embedded-wallets/integration-guide/flutter/getting-started",
+ "permanent": True,
+ },
+ {
+ "source": "/sdks/kotlin",
+ "destination": "/solutions/embedded-wallets/integration-guide/kotlin/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/sdks/kotlin/landing",
+ "destination": "/solutions/embedded-wallets/integration-guide/kotlin/getting-started",
+ "permanent": True,
+ },
+ {
+ "source": "/sdks/react-native",
+ "destination": "/solutions/embedded-wallets/integration-guide/react-native/getting-started",
+ "permanent": True,
+ },
+ {
+ "source": "/sdks/react/landing",
+ "destination": "/solutions/embedded-wallets/integration-guide/react/getting-started",
+ "permanent": True,
+ },
+ {
+ "source": "/sdks/swift",
+ "destination": "/solutions/embedded-wallets/integration-guide/swift/overview",
+ "permanent": True,
+ },
+ {
+ "source": "/sdks/swift/landing",
+ "destination": "/solutions/embedded-wallets/integration-guide/swift/getting-started",
+ "permanent": True,
+ },
+ {
+ "source": "/sdks/typescript-frontend/landing",
+ "destination": "/solutions/embedded-wallets/integration-guide/typescript/getting-started",
+ "permanent": True,
+ },
+ # ── Wallet Pages (2) ──────────────────────────────────────────────────
+ {
+ "source": "/wallets/export-wallets",
+ "destination": "/features/wallets/export-wallets",
+ "permanent": True,
+ },
+ {
+ "source": "/wallets/import-wallets",
+ "destination": "/features/wallets/import-wallets",
+ "permanent": True,
+ },
+ # ── Additional (1) ────────────────────────────────────────────────────
+ {
+ "source": "/home",
+ "destination": "/welcome",
+ "permanent": True,
+ },
+]
+
+
+def main():
+ # Validate hardcoded count
+ assert len(ORPHAN_REDIRECTS) == 70, (
+ f"Expected 70 orphan redirects, got {len(ORPHAN_REDIRECTS)}"
+ )
+
+ # ── Read docs.json ────────────────────────────────────────────────────
+ print(f"Reading {DOCS_JSON} ...")
+ with open(DOCS_JSON, "r") as f:
+ data = json.load(f)
+
+ existing_redirects = data.get("redirects", [])
+ before_count = len(existing_redirects)
+ print(f"Existing redirects: {before_count}")
+
+ # Build lookup sets for conflict detection
+ existing_sources = {}
+ for r in existing_redirects:
+ existing_sources[r["source"]] = r["destination"]
+
+ existing_destinations = set(r["destination"] for r in existing_redirects)
+
+ # ── Check for conflicts ───────────────────────────────────────────────
+ duplicates = []
+ chains = []
+ added = []
+ skipped = []
+
+ for entry in ORPHAN_REDIRECTS:
+ src = entry["source"]
+ dst = entry["destination"]
+
+ # Check 1: Source already exists as a source (duplicate)
+ if src in existing_sources:
+ existing_dst = existing_sources[src]
+ if existing_dst == dst:
+ print(
+ f" DUPLICATE (same dest, skipping): {src} -> {dst}"
+ )
+ else:
+ print(
+ f" DUPLICATE (different dest, skipping): "
+ f"{src} -> {existing_dst} (existing) vs {dst} (new)"
+ )
+ duplicates.append(entry)
+ skipped.append(entry)
+ continue
+
+ # Check 2: Source path is an existing destination (creates a chain)
+ if src in existing_destinations:
+ # Find which existing redirect(s) point to this source
+ upstream = [
+ r for r in existing_redirects if r["destination"] == src
+ ]
+ for u in upstream:
+ print(
+ f" CHAIN WARNING: {u['source']} -> {src} (existing) "
+ f"-> {dst} (new). Will create redirect chain."
+ )
+ chains.append(entry)
+ # Still add it -- chains will be fixed in Step 5
+
+ # Check 3: Flag /api-overview specifically (user requested)
+ if src == "/api-overview":
+ # Check if a wildcard variant exists
+ wildcard = "/api-overview/:slug*"
+ if wildcard in existing_sources:
+ print(
+ f" NOTE: Adding exact /api-overview redirect. "
+ f"Existing wildcard {wildcard} -> "
+ f"{existing_sources[wildcard]} also present."
+ )
+
+ added.append(entry)
+
+ # ── Append new redirects ──────────────────────────────────────────────
+ existing_redirects.extend(added)
+ data["redirects"] = existing_redirects
+ after_count = len(existing_redirects)
+
+ # ── Write back ────────────────────────────────────────────────────────
+ print(f"\nWriting {DOCS_JSON} ...")
+ with open(DOCS_JSON, "w") as f:
+ json.dump(data, f, indent=2)
+ f.write("\n") # trailing newline
+
+ # ── Summary ───────────────────────────────────────────────────────────
+ print("\n" + "=" * 60)
+ print("SUMMARY")
+ print("=" * 60)
+ print(f" Redirects before: {before_count}")
+ print(f" New entries to add: {len(ORPHAN_REDIRECTS)}")
+ print(f" Duplicates (skipped): {len(duplicates)}")
+ print(f" Chain warnings: {len(chains)}")
+ print(f" Actually added: {len(added)}")
+ print(f" Redirects after: {after_count}")
+ print()
+
+ if duplicates:
+ print("Skipped duplicates (source already exists):")
+ for d in duplicates:
+ print(f" {d['source']} -> {d['destination']}")
+ print()
+
+ if chains:
+ print("Chain warnings (source is an existing destination):")
+ print(" These will create redirect chains -- fix in Step 5.")
+ for c in chains:
+ print(f" {c['source']} -> {c['destination']}")
+ print()
+
+ expected_added = 70 - len(duplicates)
+ if len(added) == expected_added:
+ print(f"OK: Added {len(added)} redirects (70 - {len(duplicates)} duplicates).")
+ else:
+ print(
+ f"WARNING: Expected to add {expected_added} but added {len(added)}."
+ )
+ sys.exit(1)
+
+
+if __name__ == "__main__":
+ main()
diff --git a/step5-fix-existing-redirects.py b/step5-fix-existing-redirects.py
new file mode 100644
index 00000000..643543f6
--- /dev/null
+++ b/step5-fix-existing-redirects.py
@@ -0,0 +1,169 @@
+#!/usr/bin/env python3
+"""
+Step 5: Fix 36 existing redirect destinations in docs.json.
+
+For each redirect entry in docs.json's "redirects" array, if its "source"
+matches one of the 36 sources below, update its "destination" to the
+corrected value. Does NOT add new entries -- only modifies existing ones.
+"""
+
+import json
+import sys
+
+DOCS_JSON_PATH = "docs.json"
+
+# ─── The 36 fixes: source → corrected destination ───────────────────────────
+
+FIXES = {
+ # Phase 5 table (32)
+ "/api-introduction": "/api-reference/overview/intro",
+ "/integration-guides/aa-wallets": "/features/wallets/aa-wallets",
+ "/getting-started/resource-limits": "/reference/resource-limits",
+ "/passkeys/discoverable-vs-non-discoverable": "/features/authentication/passkeys/discoverable-vs-non-discoverable",
+ "/passkeys/integration": "/features/authentication/passkeys/integration",
+ "/passkeys/introduction": "/features/authentication/passkeys/introduction",
+ "/passkeys/native": "/features/authentication/passkeys/native",
+ "/passkeys/options": "/features/authentication/passkeys/options",
+ "/features/oauth": "/features/authentication/social-logins",
+ "/features/email-auth": "/features/authentication/email",
+ "/features/email-recovery": "/features/authentication/email",
+ "/getting-started/signing-automation-quickstart": "/solutions/company-wallets/quickstart",
+ "/signing-automation/overview": "/solutions/company-wallets/overview",
+ "/signing-automation/code-examples/smart-contract-management": "/solutions/company-wallets/smart-contract-management",
+ "/signing-automation/code-examples/payment-orchestration": "/solutions/company-wallets/payment-orchestration",
+ "/users/sessions": "/features/authentication/sessions",
+ "/getting-started/email-auth": "/features/authentication/email",
+ "/concepts/email-auth": "/features/authentication/email",
+ "/concepts/email-recovery": "/features/authentication/email",
+ "/integration-guides/export-wallets": "/features/wallets/export-wallets",
+ "/integration-guides/import-wallets": "/features/wallets/import-wallets",
+ "/integration-guides/webhooks": "/reference/webhooks",
+ "/users/:slug*": "/features/users/:slug*",
+ "/managing-policies/:slug*": "/features/policies/:slug*",
+ "/managing-users/:slug*": "/features/users/:slug*",
+ "/api-design/:slug*": "/api-reference/overview/:slug*",
+ "/api-overview/:slug*": "/api-reference/overview/:slug*",
+ "/ecosystems/:slug*": "/features/networks/:slug*",
+ "/ecosystem-integrations/ethereum": "/features/networks/ethereum",
+ "/ecosystem-integrations/solana": "/features/networks/solana",
+ "/ecosystem-integrations/bitcoin": "/features/networks/bitcoin",
+ "/ecosystem-integrations/index": "/features/networks/overview",
+
+ # Newly broken by orphan deletions (4)
+ "/integration-guides/sub-organization-auth": "/features/authentication/email",
+ "/integration-guides/sub-organization-recovery": "/features/authentication/email",
+ "/reference/react-components": "/solutions/embedded-wallets/integration-guide/react/getting-started",
+ "/concepts/introduction": "/get-started/about-turnkey",
+}
+
+# ─── The 2 OK-as-is redirects to verify are still present and unchanged ─────
+
+OK_AS_IS = {
+ "/sdks/react/sdk-reference": "/generated-docs/formatted/react-wallet-kit/client-context-type-add-oauth-provider",
+ "/sdks/typescript-frontend/sdk-reference": "/generated-docs/formatted/core/turnkey-client-add-oauth-provider",
+}
+
+
+def main():
+ # 1. Read docs.json
+ with open(DOCS_JSON_PATH, "r", encoding="utf-8") as f:
+ data = json.load(f)
+
+ redirects = data.get("redirects", [])
+ if not redirects:
+ print("ERROR: No 'redirects' array found in docs.json.")
+ sys.exit(1)
+
+ # Build a lookup: source -> index in redirects list
+ source_to_index = {}
+ for i, entry in enumerate(redirects):
+ source_to_index[entry["source"]] = i
+
+ # 2-4. For each of the 36 fixes, find the matching redirect and update it
+ changes_made = 0
+ sources_not_found = []
+
+ print("=" * 72)
+ print("STEP 5: Fixing 36 existing redirect destinations")
+ print("=" * 72)
+ print()
+
+ for source, new_dest in FIXES.items():
+ if source not in source_to_index:
+ sources_not_found.append(source)
+ continue
+
+ idx = source_to_index[source]
+ old_dest = redirects[idx]["destination"]
+
+ if old_dest == new_dest:
+ print(f" SKIP (already correct): {source}")
+ print(f" destination = {new_dest}")
+ print()
+ changes_made += 1 # Count as "handled" even if already correct
+ continue
+
+ # Update the destination
+ redirects[idx]["destination"] = new_dest
+ changes_made += 1
+
+ print(f" FIXED: {source}")
+ print(f" OLD: {old_dest}")
+ print(f" NEW: {new_dest}")
+ print()
+
+ # 5. Flag any of the 36 sources not found in docs.json
+ if sources_not_found:
+ print("-" * 72)
+ print(f"WARNING: {len(sources_not_found)} source(s) NOT FOUND in docs.json:")
+ for s in sources_not_found:
+ print(f" - {s}")
+ print()
+
+ # 6. Verify the 2 OK-as-is redirects are still present and unchanged
+ print("-" * 72)
+ print("Verifying 2 OK-as-is redirects:")
+ print()
+ ok_count = 0
+ for source, expected_dest in OK_AS_IS.items():
+ if source not in source_to_index:
+ print(f" MISSING: {source}")
+ print(f" Expected destination: {expected_dest}")
+ print()
+ else:
+ idx = source_to_index[source]
+ actual_dest = redirects[idx]["destination"]
+ if actual_dest == expected_dest:
+ print(f" OK: {source}")
+ print(f" destination = {actual_dest}")
+ ok_count += 1
+ else:
+ print(f" MISMATCH: {source}")
+ print(f" Expected: {expected_dest}")
+ print(f" Actual: {actual_dest}")
+ print()
+
+ # 7. Write back with 2-space indent + trailing newline
+ with open(DOCS_JSON_PATH, "w", encoding="utf-8") as f:
+ json.dump(data, f, indent=2, ensure_ascii=False)
+ f.write("\n")
+
+ # 8. Print summary
+ print("=" * 72)
+ print("SUMMARY")
+ print("=" * 72)
+ print(f" Total fixes expected: 36")
+ print(f" Redirects updated/verified: {changes_made}")
+ print(f" Sources not found: {len(sources_not_found)}")
+ print(f" OK-as-is verified: {ok_count}/2")
+ print(f" docs.json written: {DOCS_JSON_PATH}")
+ print("=" * 72)
+
+ if sources_not_found:
+ print()
+ print("NOTE: Some sources were not found. Review the warnings above.")
+ sys.exit(1)
+
+
+if __name__ == "__main__":
+ main()
diff --git a/step6-update-internal-links.py b/step6-update-internal-links.py
new file mode 100644
index 00000000..fdaec90c
--- /dev/null
+++ b/step6-update-internal-links.py
@@ -0,0 +1,561 @@
+#!/usr/bin/env python3
+"""
+Step 6: Update internal links in .mdx files.
+
+Scans all .mdx files recursively and replaces old internal link paths with
+new paths. The mapping combines:
+ - 187 nav page moves from Phase 3 (PATH_MAPPING from step2)
+ - 70 orphan redirects from Phase 4 (ORPHAN_REDIRECTS from step4)
+
+Nav page moves take precedence if the same old path appears in both.
+
+Usage:
+ python3 step6-update-internal-links.py # dry-run (default)
+ python3 step6-update-internal-links.py --write # actually write changes
+"""
+
+import os
+import re
+import sys
+from pathlib import Path
+
+# ---------------------------------------------------------------------------
+# Directory to scan
+# ---------------------------------------------------------------------------
+DOCS_ROOT = Path(__file__).resolve().parent
+
+# ---------------------------------------------------------------------------
+# Phase 3 mapping: 187 nav page moves (old path -> new path)
+# Paths WITHOUT leading slashes, matching docs.json convention.
+# ---------------------------------------------------------------------------
+NAV_PAGE_MOVES: dict[str, str] = {
+ # === Solutions (96 changed) ===
+ "embedded-wallets/overview": "solutions/embedded-wallets/overview",
+ "embedded-wallets/code-examples/embedded-consumer-wallet": "solutions/embedded-wallets/embedded-consumer-wallet",
+ "products/embedded-business-wallets/overview": "solutions/embedded-wallets/embedded-business-wallets",
+ "embedded-wallets/embedded-waas": "solutions/embedded-wallets/embedded-waas",
+ "getting-started/embedded-wallet-quickstart": "solutions/embedded-wallets/quickstart",
+ "embedded-wallets/integration-guide/overview": "solutions/embedded-wallets/integration-guide/overview",
+ # React (13)
+ "sdks/react/index": "solutions/embedded-wallets/integration-guide/react/index",
+ "sdks/react/getting-started": "solutions/embedded-wallets/integration-guide/react/getting-started",
+ "sdks/react/auth": "solutions/embedded-wallets/integration-guide/react/auth",
+ "sdks/react/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/react/using-embedded-wallets",
+ "sdks/react/using-external-wallets/overview": "solutions/embedded-wallets/integration-guide/react/using-external-wallets/overview",
+ "sdks/react/using-external-wallets/authentication": "solutions/embedded-wallets/integration-guide/react/using-external-wallets/authentication",
+ "sdks/react/using-external-wallets/connecting": "solutions/embedded-wallets/integration-guide/react/using-external-wallets/connecting",
+ "sdks/react/signing": "solutions/embedded-wallets/integration-guide/react/signing",
+ "sdks/react/ui-customization": "solutions/embedded-wallets/integration-guide/react/ui-customization",
+ "sdks/react/sub-organization-customization": "solutions/embedded-wallets/integration-guide/react/sub-organization-customization",
+ "sdks/react/advanced-api-requests": "solutions/embedded-wallets/integration-guide/react/advanced-api-requests",
+ "sdks/react/advanced-backend-authentication": "solutions/embedded-wallets/integration-guide/react/advanced-backend-authentication",
+ "sdks/react/migrating-sdk-react": "solutions/embedded-wallets/integration-guide/react/migrating-sdk-react",
+ "sdks/react/troubleshooting": "solutions/embedded-wallets/integration-guide/react/troubleshooting",
+ "sdks/react/legacy": "solutions/embedded-wallets/integration-guide/react/legacy",
+ # React Native (10)
+ "sdks/react-native/overview": "solutions/embedded-wallets/integration-guide/react-native/overview",
+ "sdks/react-native/getting-started": "solutions/embedded-wallets/integration-guide/react-native/getting-started",
+ "sdks/react-native/authentication/overview": "solutions/embedded-wallets/integration-guide/react-native/authentication/overview",
+ "sdks/react-native/authentication/email-sms": "solutions/embedded-wallets/integration-guide/react-native/authentication/email-sms",
+ "sdks/react-native/authentication/passkey": "solutions/embedded-wallets/integration-guide/react-native/authentication/passkey",
+ "sdks/react-native/authentication/social-logins": "solutions/embedded-wallets/integration-guide/react-native/authentication/social-logins",
+ "sdks/react-native/sub-organization-customization": "solutions/embedded-wallets/integration-guide/react-native/sub-organization-customization",
+ "sdks/react-native/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/react-native/using-embedded-wallets",
+ "sdks/react-native/signing": "solutions/embedded-wallets/integration-guide/react-native/signing",
+ "sdks/react-native/advanced-api-requests": "solutions/embedded-wallets/integration-guide/react-native/advanced-api-requests",
+ # TypeScript (6)
+ "sdks/typescript-frontend/index": "solutions/embedded-wallets/integration-guide/typescript/index",
+ "sdks/typescript-frontend/getting-started": "solutions/embedded-wallets/integration-guide/typescript/getting-started",
+ "sdks/typescript-frontend/auth": "solutions/embedded-wallets/integration-guide/typescript/auth",
+ "sdks/typescript-frontend/advanced-backend-authentication": "solutions/embedded-wallets/integration-guide/typescript/advanced-backend-authentication",
+ "sdks/typescript-frontend/advanced-api-requests": "solutions/embedded-wallets/integration-guide/typescript/advanced-api-requests",
+ "sdks/typescript-frontend/legacy": "solutions/embedded-wallets/integration-guide/typescript/legacy",
+ # Flutter (10)
+ "sdks/flutter/index": "solutions/embedded-wallets/integration-guide/flutter/index",
+ "sdks/flutter/getting-started": "solutions/embedded-wallets/integration-guide/flutter/getting-started",
+ "sdks/flutter/authentication/overview": "solutions/embedded-wallets/integration-guide/flutter/authentication/overview",
+ "sdks/flutter/authentication/email-sms": "solutions/embedded-wallets/integration-guide/flutter/authentication/email-sms",
+ "sdks/flutter/authentication/passkey": "solutions/embedded-wallets/integration-guide/flutter/authentication/passkey",
+ "sdks/flutter/authentication/social-logins": "solutions/embedded-wallets/integration-guide/flutter/authentication/social-logins",
+ "sdks/flutter/sub-organization-customization": "solutions/embedded-wallets/integration-guide/flutter/sub-organization-customization",
+ "sdks/flutter/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/flutter/using-embedded-wallets",
+ "sdks/flutter/signing": "solutions/embedded-wallets/integration-guide/flutter/signing",
+ "sdks/flutter/advanced-api-requests": "solutions/embedded-wallets/integration-guide/flutter/advanced-api-requests",
+ # Swift (11)
+ "sdks/swift/overview": "solutions/embedded-wallets/integration-guide/swift/overview",
+ "sdks/swift/getting-started": "solutions/embedded-wallets/integration-guide/swift/getting-started",
+ "sdks/swift/authentication/overview": "solutions/embedded-wallets/integration-guide/swift/authentication/overview",
+ "sdks/swift/authentication/email-sms": "solutions/embedded-wallets/integration-guide/swift/authentication/email-sms",
+ "sdks/swift/authentication/passkey": "solutions/embedded-wallets/integration-guide/swift/authentication/passkey",
+ "sdks/swift/authentication/social-logins": "solutions/embedded-wallets/integration-guide/swift/authentication/social-logins",
+ "sdks/swift/signing": "solutions/embedded-wallets/integration-guide/swift/signing",
+ "sdks/swift/sub-organization-customization": "solutions/embedded-wallets/integration-guide/swift/sub-organization-customization",
+ "sdks/swift/advanced-api-requests": "solutions/embedded-wallets/integration-guide/swift/advanced-api-requests",
+ "sdks/swift/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/swift/using-embedded-wallets",
+ "sdks/swift/advanced-backend-authentication": "solutions/embedded-wallets/integration-guide/swift/advanced-backend-authentication",
+ # Kotlin (11)
+ "sdks/kotlin/overview": "solutions/embedded-wallets/integration-guide/kotlin/overview",
+ "sdks/kotlin/getting-started": "solutions/embedded-wallets/integration-guide/kotlin/getting-started",
+ "sdks/kotlin/authentication/overview": "solutions/embedded-wallets/integration-guide/kotlin/authentication/overview",
+ "sdks/kotlin/authentication/email-sms": "solutions/embedded-wallets/integration-guide/kotlin/authentication/email-sms",
+ "sdks/kotlin/authentication/passkey": "solutions/embedded-wallets/integration-guide/kotlin/authentication/passkey",
+ "sdks/kotlin/authentication/social-logins": "solutions/embedded-wallets/integration-guide/kotlin/authentication/social-logins",
+ "sdks/kotlin/authentication/rp-id-setup": "solutions/embedded-wallets/integration-guide/kotlin/authentication/rp-id-setup",
+ "sdks/kotlin/sub-organization-customization": "solutions/embedded-wallets/integration-guide/kotlin/sub-organization-customization",
+ "sdks/kotlin/using-embedded-wallets": "solutions/embedded-wallets/integration-guide/kotlin/using-embedded-wallets",
+ "sdks/kotlin/signing": "solutions/embedded-wallets/integration-guide/kotlin/signing",
+ "sdks/kotlin/advanced-api-requests": "solutions/embedded-wallets/integration-guide/kotlin/advanced-api-requests",
+ # Company Wallets (10)
+ "company-wallets/overview": "solutions/company-wallets/overview",
+ "company-wallets/code-examples/payment-orchestration": "solutions/company-wallets/payment-orchestration",
+ "company-wallets/code-examples/smart-contract-management": "solutions/company-wallets/smart-contract-management",
+ "company-wallets/use-cases/agentic-wallets": "solutions/company-wallets/agentic-wallets",
+ "getting-started/company-wallets-quickstart": "solutions/company-wallets/quickstart",
+ "company-wallets/integration-guide/overview": "solutions/company-wallets/integration-guide/overview",
+ "sdks/javascript-server": "solutions/company-wallets/integration-guide/javascript-server",
+ "sdks/golang": "solutions/company-wallets/integration-guide/golang",
+ "sdks/ruby": "solutions/company-wallets/integration-guide/ruby",
+ "sdks/rust": "solutions/company-wallets/integration-guide/rust",
+ "sdks/python": "solutions/company-wallets/integration-guide/python",
+ # Key Management (3)
+ "products/key-management/overview": "solutions/key-management/overview",
+ "products/key-management/examples/encryption-key-storage": "solutions/key-management/encryption-key-storage",
+ "products/key-management/examples/enterprise-disaster-recovery": "solutions/key-management/enterprise-disaster-recovery",
+ # Cookbooks (14)
+ "cookbook/landing": "solutions/cookbooks/landing",
+ "cookbook/morpho": "solutions/cookbooks/morpho",
+ "cookbook/aave": "solutions/cookbooks/aave",
+ "cookbook/breeze": "solutions/cookbooks/breeze",
+ "cookbook/yieldxyz": "solutions/cookbooks/yieldxyz",
+ "cookbook/jupiter": "solutions/cookbooks/jupiter",
+ "cookbook/lifi": "solutions/cookbooks/lifi",
+ "cookbook/0x": "solutions/cookbooks/0x",
+ "cookbook/relay": "solutions/cookbooks/relay",
+ "cookbook/polymarket-builders": "solutions/cookbooks/polymarket-builders",
+ "cookbook/base-builder-codes": "solutions/cookbooks/base-builder-codes",
+ "cookbook/brale": "solutions/cookbooks/brale",
+ "reference/tron-gasless-transactions": "solutions/cookbooks/tron-gasless-transactions",
+
+ # === Get started (7 changed) ===
+ "home": "get-started/about-turnkey",
+ "getting-started/quickstart": "get-started/quickstart",
+ "developer-reference/using-llms": "get-started/using-llms",
+ "ai/skills": "get-started/ai-skills",
+ "getting-started/examples": "get-started/examples",
+ "production-checklist/production-checklist": "get-started/production-checklist",
+ "production-checklist/backup-recovery": "get-started/backup-recovery",
+
+ # === Features (71 changed) ===
+ # Organizations (2)
+ "concepts/organizations": "features/organizations",
+ "concepts/sub-organizations": "features/sub-organizations",
+ # Users (4)
+ "concepts/users/introduction": "features/users/introduction",
+ "concepts/users/credentials": "features/users/credentials",
+ "concepts/users/root-quorum": "features/users/root-quorum",
+ "concepts/users/best-practices": "features/users/best-practices",
+ # Authentication (14)
+ "authentication/overview": "features/authentication/overview",
+ "authentication/email": "features/authentication/email",
+ "authentication/social-logins": "features/authentication/social-logins",
+ "authentication/sms": "features/authentication/sms",
+ "authentication/passkeys/introduction": "features/authentication/passkeys/introduction",
+ "authentication/passkeys/integration": "features/authentication/passkeys/integration",
+ "authentication/passkeys/options": "features/authentication/passkeys/options",
+ "authentication/passkeys/native": "features/authentication/passkeys/native",
+ "authentication/passkeys/discoverable-vs-non-discoverable": "features/authentication/passkeys/discoverable-vs-non-discoverable",
+ "authentication/backend-setup": "features/authentication/backend-setup",
+ "authentication/bring-your-own-auth": "features/authentication/bring-your-own-auth",
+ "reference/auth-proxy": "features/authentication/auth-proxy",
+ "authentication/sessions": "features/authentication/sessions",
+ "authentication/proxying-signed-requests": "features/authentication/proxying-signed-requests",
+ # Wallet and key management (7)
+ "concepts/wallets": "features/wallets",
+ "products/company-wallets/features/import-wallets": "features/wallets/import-wallets",
+ "products/company-wallets/features/export-wallets": "features/wallets/export-wallets",
+ "wallets/pregenerated-wallets": "features/wallets/pregenerated-wallets",
+ "wallets/claim-links": "features/wallets/claim-links",
+ "embedded-wallets/send-crypto-via-url": "features/wallets/send-crypto-via-url",
+ "reference/aa-wallets": "features/wallets/aa-wallets",
+ # Chain support / Networks (19)
+ "networks/overview": "features/networks/overview",
+ "networks/ethereum": "features/networks/ethereum",
+ "networks/solana": "features/networks/solana",
+ "networks/solana-transaction-construction": "features/networks/solana-transaction-construction",
+ "networks/solana-rent-refunds": "features/networks/solana-rent-refunds",
+ "networks/bitcoin": "features/networks/bitcoin",
+ "networks/spark": "features/networks/spark",
+ "networks/hyperliquid": "features/networks/hyperliquid",
+ "networks/cosmos": "features/networks/cosmos",
+ "networks/tron": "features/networks/tron",
+ "networks/sui": "features/networks/sui",
+ "networks/sei": "features/networks/sei",
+ "networks/stacks": "features/networks/stacks",
+ "networks/aptos": "features/networks/aptos",
+ "networks/tempo": "features/networks/tempo",
+ "networks/movement": "features/networks/movement",
+ "networks/iota": "features/networks/iota",
+ "networks/doge": "features/networks/doge",
+ "networks/others": "features/networks/others",
+ # Policies (13)
+ "concepts/policies/overview": "features/policies/overview",
+ "concepts/policies/quickstart": "features/policies/quickstart",
+ "concepts/policies/language": "features/policies/language",
+ "concepts/policies/smart-contract-interfaces": "features/policies/smart-contract-interfaces",
+ "concepts/policies/examples/access-control": "features/policies/examples/access-control",
+ "company-wallets/co-signing-transactions": "features/policies/examples/co-signing-transactions",
+ "concepts/policies/examples/signing-control": "features/policies/examples/signing-control",
+ "concepts/policies/examples/ethereum": "features/policies/examples/ethereum",
+ "concepts/policies/examples/solana": "features/policies/examples/solana",
+ "concepts/policies/examples/tron": "features/policies/examples/tron",
+ "concepts/policies/examples/bitcoin": "features/policies/examples/bitcoin",
+ "concepts/policies/examples/tempo": "features/policies/examples/tempo",
+ # Delegated access (4)
+ "concepts/policies/delegated-access-overview": "features/policies/delegated-access/overview",
+ "concepts/policies/delegated-access-frontend": "features/policies/delegated-access/frontend",
+ "concepts/policies/delegated-access-backend": "features/policies/delegated-access/backend",
+ "products/embedded-wallets/features/agentic-wallets": "features/policies/delegated-access/agentic-wallets",
+ # Transaction management (5)
+ "concepts/transaction-management": "features/transaction-management",
+ "concepts/broadcasting": "features/transaction-management/broadcasting",
+ "embedded-wallets/code-examples/sending-sponsored-transactions": "features/transaction-management/sending-sponsored-transactions",
+ "embedded-wallets/code-examples/sending-sponsored-solana-transactions": "features/transaction-management/sending-sponsored-solana-transactions",
+ "concepts/balances": "features/transaction-management/balances",
+ "wallets/fiat-on-ramp": "features/transaction-management/fiat-on-ramp",
+ # Verifiable Cloud (3)
+ "products/verifiable-cloud/overview": "features/verifiable-cloud/overview",
+ "products/verifiable-cloud/onboarding": "features/verifiable-cloud/onboarding",
+ "getting-started/verifiable-cloud-quickstart": "features/verifiable-cloud/quickstart",
+
+ # === Reference (4 changed) ===
+ "concepts/resource-limits": "reference/resource-limits",
+ "developer-reference/webhooks": "reference/webhooks",
+ "getting-started/migration-guide": "reference/migration-guide",
+ "faq": "reference/faq",
+
+ # === API reference (3 changed) ===
+ "developer-reference/api-overview/intro": "api-reference/overview/intro",
+ "developer-reference/api-overview/stamps": "api-reference/overview/stamps",
+ "developer-reference/api-overview/errors": "api-reference/overview/errors",
+
+ # === SDK reference (4 changed) ===
+ "category/web3-libraries": "sdks/web3/overview",
+ "wallets/wagmi": "sdks/web3/wagmi",
+ "category/advanced": "sdks/advanced/overview",
+ "embedded-wallets/code-examples/client-side-signing": "sdks/advanced/client-side-signing",
+
+ # === Security (2 changed) ===
+ "category/security": "security/overview",
+ "products/company-wallets/features/security/remote-attestation": "security/remote-attestation",
+}
+
+# ---------------------------------------------------------------------------
+# Phase 4: 70 orphan redirects (source -> destination)
+# Paths WITH leading slashes (redirect format).
+# ---------------------------------------------------------------------------
+ORPHAN_REDIRECTS_RAW: list[dict[str, str]] = [
+ # ── Product Features (14) ─────────────────────────────────────────────
+ {"source": "/products/company-wallets/features/dashboard", "destination": "/solutions/company-wallets/overview"},
+ {"source": "/products/company-wallets/features/multi-chain-support", "destination": "/features/networks/overview"},
+ {"source": "/products/company-wallets/features/off-chain-contracts", "destination": "/solutions/company-wallets/overview"},
+ {"source": "/products/company-wallets/features/scoped-api-key", "destination": "/solutions/company-wallets/overview"},
+ {"source": "/products/company-wallets/features/security/compliance", "destination": "/security/our-approach"},
+ {"source": "/products/company-wallets/features/security/quorum-os", "destination": "/security/secure-enclaves"},
+ {"source": "/products/company-wallets/features/security/secure-hardware", "destination": "/security/secure-enclaves"},
+ {"source": "/products/company-wallets/policy-engine", "destination": "/features/policies/quickstart"},
+ {"source": "/products/embedded-wallets/features/export-wallets", "destination": "/features/wallets/export-wallets"},
+ {"source": "/products/embedded-wallets/features/fiat-on-ramp", "destination": "/features/transaction-management/fiat-on-ramp"},
+ {"source": "/products/embedded-wallets/features/gas-sponsorship", "destination": "/features/transaction-management/broadcasting"},
+ {"source": "/products/embedded-wallets/features/import-wallets", "destination": "/features/wallets/import-wallets"},
+ {"source": "/products/embedded-wallets/features/multi-chain-support", "destination": "/features/networks/overview"},
+ {"source": "/products/embedded-wallets/features/policy-engine", "destination": "/features/policies/quickstart"},
+ # ── API Pages (8) ─────────────────────────────────────────────────────
+ {"source": "/api-overview", "destination": "/api-reference/overview/intro"},
+ {"source": "/api-reference/activities/submit-a-raw-transaction-for-broadcasting", "destination": "/api-reference/activities/overview"},
+ {"source": "/api-reference/activities/submit-a-transaction-intent-for-broadcasting", "destination": "/api-reference/activities/overview"},
+ {"source": "/api-reference/overview", "destination": "/api-reference/overview/intro"},
+ {"source": "/api-reference/queries/get-gas-usage-and-limits", "destination": "/api-reference/queries/get-gas-usage"},
+ {"source": "/api-reference/queries/get-nonces-for-an-address", "destination": "/api-reference/queries/get-nonces"},
+ {"source": "/api-reference/queries/get-suborgs", "destination": "/api-reference/queries/get-sub-organizations"},
+ {"source": "/api-reference/queries/get-verified-suborgs", "destination": "/api-reference/queries/get-verified-sub-organizations"},
+ # ── Code Examples (16) ────────────────────────────────────────────────
+ {"source": "/company-wallets/code-examples/balance-sweeper", "destination": "/solutions/company-wallets/overview"},
+ {"source": "/company-wallets/code-examples/sending-sponsored-transactions", "destination": "/features/transaction-management/broadcasting"},
+ {"source": "/company-wallets/code-examples/signing-transactions", "destination": "/solutions/company-wallets/overview"},
+ {"source": "/embedded-wallets/code-examples/add-credential", "destination": "/solutions/embedded-wallets/integration-guide/react/index"},
+ {"source": "/embedded-wallets/code-examples/authenticate-user-email", "destination": "/solutions/embedded-wallets/integration-guide/react/auth"},
+ {"source": "/embedded-wallets/code-examples/authenticate-user-passkey", "destination": "/solutions/embedded-wallets/integration-guide/react/sub-organization-customization"},
+ {"source": "/embedded-wallets/code-examples/create-passkey-session", "destination": "/solutions/embedded-wallets/integration-guide/react/auth"},
+ {"source": "/embedded-wallets/code-examples/create-sub-org-passkey", "destination": "/solutions/embedded-wallets/integration-guide/react/sub-organization-customization"},
+ {"source": "/embedded-wallets/code-examples/create-user-email", "destination": "/solutions/embedded-wallets/integration-guide/react/sub-organization-customization"},
+ {"source": "/embedded-wallets/code-examples/email-recovery", "destination": "/features/authentication/email"},
+ {"source": "/embedded-wallets/code-examples/export", "destination": "/solutions/embedded-wallets/integration-guide/react/using-embedded-wallets"},
+ {"source": "/embedded-wallets/code-examples/fiat-on-ramp", "destination": "/features/transaction-management/fiat-on-ramp"},
+ {"source": "/embedded-wallets/code-examples/import", "destination": "/solutions/embedded-wallets/integration-guide/react/using-embedded-wallets"},
+ {"source": "/embedded-wallets/code-examples/signing-transactions", "destination": "/solutions/embedded-wallets/integration-guide/react/signing"},
+ {"source": "/embedded-wallets/code-examples/social-linking", "destination": "/solutions/embedded-wallets/integration-guide/react/auth"},
+ {"source": "/embedded-wallets/code-examples/wallet-auth", "destination": "/solutions/embedded-wallets/integration-guide/react/using-external-wallets/overview"},
+ # ── Overview/Landing Pages (7) ────────────────────────────────────────
+ {"source": "/category/code-examples", "destination": "/solutions/embedded-wallets/overview"},
+ {"source": "/category/code-examples-1", "destination": "/solutions/company-wallets/overview"},
+ {"source": "/concepts/overview", "destination": "/get-started/about-turnkey"},
+ {"source": "/embedded-wallets/demos", "destination": "/solutions/embedded-wallets/quickstart"},
+ {"source": "/embedded-wallets/features/overview", "destination": "/solutions/embedded-wallets/overview"},
+ {"source": "/products/key-management/examples/overview", "destination": "/solutions/key-management/overview"},
+ {"source": "/products/verifiable-cloud/lifecycle", "destination": "/features/verifiable-cloud/overview"},
+ # ── Auth/Getting-Started/Misc (9) ─────────────────────────────────────
+ {"source": "/authentication/credentials", "destination": "/features/users/credentials"},
+ {"source": "/authentication/otp-migration-guide", "destination": "/features/authentication/overview"},
+ {"source": "/cookbook/gelato", "destination": "/sdks/web3/gas-station"},
+ {"source": "/developer-reference/api-overview/queries", "destination": "/api-reference/queries/overview"},
+ {"source": "/developer-reference/api-overview/submissions", "destination": "/api-reference/activities/overview"},
+ {"source": "/embedded-wallets/sub-organization-auth", "destination": "/features/authentication/email"},
+ {"source": "/embedded-wallets/sub-organization-recovery", "destination": "/features/authentication/email"},
+ {"source": "/getting-started", "destination": "/get-started/about-turnkey"},
+ {"source": "/getting-started/launch-checklist", "destination": "/get-started/production-checklist"},
+ # ── Production Checklists (2) ─────────────────────────────────────────
+ {"source": "/production-checklist/company-wallet", "destination": "/solutions/company-wallets/integration-guide/overview"},
+ {"source": "/production-checklist/embedded-wallet", "destination": "/solutions/embedded-wallets/integration-guide/overview"},
+ # ── SDK Pages (11) ────────────────────────────────────────────────────
+ {"source": "/reference/embedded-wallet-kit", "destination": "/solutions/embedded-wallets/integration-guide/react/getting-started"},
+ {"source": "/reference/solana-gasless-transactions", "destination": "/features/transaction-management"},
+ {"source": "/sdks/cli", "destination": "/sdks/introduction"},
+ {"source": "/sdks/flutter/landing", "destination": "/solutions/embedded-wallets/integration-guide/flutter/getting-started"},
+ {"source": "/sdks/kotlin", "destination": "/solutions/embedded-wallets/integration-guide/kotlin/overview"},
+ {"source": "/sdks/kotlin/landing", "destination": "/solutions/embedded-wallets/integration-guide/kotlin/getting-started"},
+ {"source": "/sdks/react-native", "destination": "/solutions/embedded-wallets/integration-guide/react-native/getting-started"},
+ {"source": "/sdks/react/landing", "destination": "/solutions/embedded-wallets/integration-guide/react/getting-started"},
+ {"source": "/sdks/swift", "destination": "/solutions/embedded-wallets/integration-guide/swift/overview"},
+ {"source": "/sdks/swift/landing", "destination": "/solutions/embedded-wallets/integration-guide/swift/getting-started"},
+ {"source": "/sdks/typescript-frontend/landing", "destination": "/solutions/embedded-wallets/integration-guide/typescript/getting-started"},
+ # ── Wallet Pages (2) ──────────────────────────────────────────────────
+ {"source": "/wallets/export-wallets", "destination": "/features/wallets/export-wallets"},
+ {"source": "/wallets/import-wallets", "destination": "/features/wallets/import-wallets"},
+ # ── Additional (1) ────────────────────────────────────────────────────
+ {"source": "/home", "destination": "/welcome"},
+]
+
+
+# ---------------------------------------------------------------------------
+# Image / asset path prefixes to skip
+# ---------------------------------------------------------------------------
+SKIP_PREFIXES = (
+ "/images/",
+ "/image/",
+ "/img/",
+ "/logo/",
+ "/logos/",
+ "/assets/",
+ "/static/",
+ "/favicon",
+ "/api/", # skip raw API endpoint URLs
+)
+
+
+def build_combined_mapping() -> dict[str, str]:
+ """
+ Build a single mapping of /old-path -> /new-path (with leading slashes).
+
+ Nav page moves (187) take precedence over orphan redirects (70).
+ """
+ combined: dict[str, str] = {}
+
+ # 1. Add orphan redirects first (lower precedence).
+ # They already have leading slashes.
+ for entry in ORPHAN_REDIRECTS_RAW:
+ old = entry["source"] # e.g. "/products/company-wallets/features/dashboard"
+ new = entry["destination"] # e.g. "/solutions/company-wallets/overview"
+ combined[old] = new
+
+ # 2. Add nav page moves (higher precedence, overwrites orphan entries).
+ # These do NOT have leading slashes, so we add them.
+ for old_no_slash, new_no_slash in NAV_PAGE_MOVES.items():
+ old = "/" + old_no_slash
+ new = "/" + new_no_slash
+ combined[old] = new
+
+ return combined
+
+
+def build_regex(mapping: dict[str, str]) -> re.Pattern:
+ """
+ Build a compiled regex that matches any old path in the mapping
+ within markdown links or JSX href attributes.
+
+ The regex matches these contexts:
+ - Markdown: ](/old-path) ](/old-path#anchor) ](/old-path "title")
+ - JSX: href="/old-path" href="/old-path#anchor"
+
+ It uses a negative lookbehind to avoid matching inside longer paths.
+ For example, /networks/overview should NOT match the "/networks/overview"
+ portion of /features/networks/overview.
+
+ Strategy:
+ - Sort paths longest-first so longer paths match before shorter ones.
+ - Use a lookbehind for ( or " (the characters that precede paths in
+ markdown links and JSX attributes).
+ - Use a lookahead to ensure the path ends at a boundary: ) # " space
+ or end-of-string.
+ - Require that the character before the / is ( or " — this prevents
+ partial matches like /features/networks/overview matching as
+ /networks/overview because the char before /networks would be "s"
+ not ( or ".
+ """
+ # Sort longest first to prevent shorter paths from matching first
+ sorted_paths = sorted(mapping.keys(), key=len, reverse=True)
+
+ # Escape each path for regex
+ escaped_paths = [re.escape(p) for p in sorted_paths]
+
+ # Join with alternation
+ alternation = "|".join(escaped_paths)
+
+ # The pattern:
+ # (?<=[\("]) — preceded by ( or "
+ # (one of the old paths)
+ # (?=[)#" \n]|$) — followed by ) # " space newline or end
+ pattern = rf'(?<=[\("])({alternation})(?=[)#" \n]|$)'
+
+ return re.compile(pattern)
+
+
+def should_skip_line(line: str) -> bool:
+ """Return True if this line should not be modified."""
+ stripped = line.lstrip()
+ # Skip import statements (snippet imports)
+ if stripped.startswith("import "):
+ return True
+ return False
+
+
+def process_file(
+ filepath: Path,
+ regex: re.Pattern,
+ mapping: dict[str, str],
+ dry_run: bool,
+) -> int:
+ """
+ Process a single .mdx file. Returns the number of replacements made.
+ """
+ try:
+ content = filepath.read_text(encoding="utf-8")
+ except (UnicodeDecodeError, OSError) as e:
+ print(f" WARNING: Could not read {filepath}: {e}")
+ return 0
+
+ lines = content.split("\n")
+ total_replacements = 0
+ new_lines = []
+
+ for line in lines:
+ if should_skip_line(line):
+ new_lines.append(line)
+ continue
+
+ def replace_match(m: re.Match) -> str:
+ old_path = m.group(1)
+ new_path = mapping.get(old_path)
+ if new_path is None:
+ return m.group(0)
+
+ # Extra safety: check that the old_path is not an image/asset path
+ for prefix in SKIP_PREFIXES:
+ if old_path.startswith(prefix):
+ return m.group(0)
+
+ return new_path
+
+ new_line, count = regex.subn(replace_match, line)
+ total_replacements += count
+ new_lines.append(new_line)
+
+ if total_replacements > 0 and not dry_run:
+ filepath.write_text("\n".join(new_lines), encoding="utf-8")
+
+ return total_replacements
+
+
+def main() -> None:
+ dry_run = "--write" not in sys.argv
+
+ if dry_run:
+ print("=" * 60)
+ print("DRY RUN — no files will be modified.")
+ print("Run with --write to apply changes.")
+ print("=" * 60)
+ print()
+
+ # ── Build combined mapping ────────────────────────────────────────────
+ mapping = build_combined_mapping()
+
+ nav_count = len(NAV_PAGE_MOVES)
+ orphan_count = len(ORPHAN_REDIRECTS_RAW)
+ combined_count = len(mapping)
+
+ print(f"Nav page moves: {nav_count}")
+ print(f"Orphan redirects: {orphan_count}")
+ print(f"Combined unique paths: {combined_count}")
+
+ # Show any overlapping keys
+ overlap_count = nav_count + orphan_count - combined_count
+ if overlap_count > 0:
+ print(f"Overlapping keys: {overlap_count} (nav move takes precedence)")
+
+ print()
+
+ # ── Build regex ───────────────────────────────────────────────────────
+ regex = build_regex(mapping)
+
+ # ── Walk all .mdx files ───────────────────────────────────────────────
+ mdx_files: list[Path] = []
+ for root, dirs, files in os.walk(DOCS_ROOT):
+ # Skip hidden directories and node_modules
+ dirs[:] = [
+ d for d in dirs
+ if not d.startswith(".") and d != "node_modules"
+ ]
+ for fname in files:
+ if fname.endswith(".mdx"):
+ mdx_files.append(Path(root) / fname)
+
+ mdx_files.sort()
+ print(f"Found {len(mdx_files)} .mdx files to scan.\n")
+
+ # ── Process each file ─────────────────────────────────────────────────
+ files_modified = 0
+ total_replacements = 0
+ modified_details: list[tuple[str, int]] = []
+
+ for filepath in mdx_files:
+ count = process_file(filepath, regex, mapping, dry_run)
+ if count > 0:
+ files_modified += 1
+ total_replacements += count
+ rel_path = filepath.relative_to(DOCS_ROOT)
+ modified_details.append((str(rel_path), count))
+
+ # ── Summary ───────────────────────────────────────────────────────────
+ print("=" * 60)
+ print("RESULTS")
+ print("=" * 60)
+
+ if modified_details:
+ print(f"\nFiles with link updates ({files_modified}):\n")
+ for rel_path, count in modified_details:
+ print(f" {rel_path:70s} {count:3d} replacement(s)")
+
+ print()
+ print(f" Total .mdx files scanned: {len(mdx_files)}")
+ print(f" Files modified: {files_modified}")
+ print(f" Total replacements: {total_replacements}")
+ print()
+
+ if dry_run:
+ print("This was a DRY RUN. No files were changed.")
+ print("Run with --write to apply changes.")
+ else:
+ print("Changes have been written to disk.")
+
+
+if __name__ == "__main__":
+ main()
diff --git a/styles.css b/styles.css
index f358d17c..40e424e4 100644
--- a/styles.css
+++ b/styles.css
@@ -1,27 +1,24 @@
/* Custom Dropdown for SMS Price Lookup */
.sms-price-lookup-container {
- /* Container needs relative positioning for absolute list */
position: relative;
margin-top: 1rem;
margin-bottom: 1rem;
}
.sms-country-trigger {
- /* Make button look like a select input */
display: block;
width: 100%;
padding: 0.5rem 0.75rem;
font-size: 1rem;
- font-family: inherit; /* Use site's font */
+ font-family: inherit;
line-height: 1.5;
- color: #495057; /* Standard text color */
+ color: #495057;
background-color: #fff;
background-clip: padding-box;
- border: 1px solid #ced4da; /* Standard border */
+ border: 1px solid #ced4da;
border-radius: 0.25rem;
text-align: left;
cursor: pointer;
- /* Add space for a dropdown arrow indicator */
padding-right: 2rem;
background-image: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3e%3cpath fill='none' stroke='%23343a40' stroke-linecap='round' stroke-linejoin='round' stroke-width='2' d='M2 5l6 6 6-6'/%3e%3c/svg%3e");
background-repeat: no-repeat;
@@ -30,19 +27,18 @@
}
.sms-country-list {
- /* Style the dropdown list */
- display: none; /* Hidden by default */
+ display: none;
position: absolute;
- top: 100%; /* Position below trigger */
+ top: 100%;
left: 0;
width: 100%;
- max-height: 200px; /* Fixed height with scroll */
+ max-height: 200px;
overflow-y: auto;
background-color: #fff;
border: 1px solid #ced4da;
- border-top: none; /* Avoid double border with trigger */
+ border-top: none;
border-radius: 0 0 0.25rem 0.25rem;
- z-index: 1000; /* Ensure it's on top */
+ z-index: 1000;
box-shadow: 0 0.5rem 1rem rgba(0, 0, 0, 0.15);
margin: 0;
padding: 0;
@@ -50,7 +46,6 @@
}
.sms-country-item {
- /* Style individual country items */
display: block;
width: 100%;
padding: 0.5rem 0.75rem;
@@ -61,21 +56,1743 @@
background-color: transparent;
border: none;
cursor: pointer;
- white-space: nowrap; /* Prevent wrapping */
+ white-space: nowrap;
}
.sms-country-item:hover,
.sms-country-item:focus {
- background-color: #f8f9fa; /* Subtle hover effect */
+ background-color: #f8f9fa;
color: #16181b;
outline: none;
}
-/* CSS to control visibility based on data-open attribute */
-#hidden-content-simple[data-open="false"] {
+#hidden-content-simple[data-open="false"] { display: none; }
+#hidden-content-simple[data-open="true"] { display: block; }
+
+/* ============================================================
+ ABC Favorit — hero headline only
+ ============================================================ */
+
+@font-face {
+ font-family: 'ABC Favorit';
+ src: url('/fonts/ABCFavorit-Regular.woff2') format('woff2');
+ font-weight: 400;
+ font-style: normal;
+ font-display: swap;
+}
+
+@font-face {
+ font-family: 'ABC Favorit';
+ src: url('/fonts/ABCFavorit-Bold.woff2') format('woff2'),
+ url('/fonts/ABCFavorit-Bold.woff') format('woff');
+ font-weight: 700;
+ font-style: normal;
+ font-display: swap;
+}
+
+/* Home tab — Untitled UI icon via mask (matches feature cards) */
+a.nav-tabs-item[href="/welcome"] > img {
+ display: none !important;
+}
+
+a.nav-tabs-item[href="/welcome"]::before {
+ content: "";
+ display: block;
+ width: 1rem;
+ height: 1rem;
+ flex-shrink: 0;
+ background-color: currentColor;
+ mask-image: url(/images/icons/home-02.svg);
+ mask-size: contain;
+ mask-repeat: no-repeat;
+ mask-position: center;
+ -webkit-mask-image: url(/images/icons/home-02.svg);
+ -webkit-mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+ -webkit-mask-position: center;
+}
+
+a.nav-tabs-item[data-active="true"],
+a.nav-tabs-item[data-active="true"].text-gray-800 {
+ color: #4c48ff !important;
+ text-shadow: none !important;
+}
+
+.dark a.nav-tabs-item[data-active="true"],
+.dark a.nav-tabs-item[data-active="true"].dark\:text-gray-200 {
+ color: #5B68FF !important;
+ text-shadow: none !important;
+}
+
+a.nav-tabs-item[href="/welcome"][data-active="true"]::before {
+ background-color: #4c48ff !important;
+}
+
+.dark a.nav-tabs-item[href="/welcome"][data-active="true"]::before {
+ background-color: #5B68FF !important;
+}
+
+/* ============================================================
+ Welcome page — align with navbar max-w-8xl + px-12
+ Mintlify wraps main content in .scroll-mt with peer-based max-w-3xl / max-w-8xl;
+ force that wrapper full width so .tk-page can use the full 92rem column.
+ ============================================================ */
+
+.scroll-mt-\[var\(--scroll-mt\)\]:has(.tk-page) {
+ max-width: none !important;
+ width: 100% !important;
+ margin-inline: 0 !important;
+ padding-inline: 0 !important;
+}
+
+#content-container:has(.tk-page) > .flex.flex-row-reverse {
+ flex-direction: row !important;
+}
+
+#content-container:has(.tk-page) #content-area {
+ width: 100% !important;
+ max-width: none !important;
+ padding: 0 !important;
+ margin: 0 !important;
+}
+
+#content-container:has(.tk-page) #sidebar {
+ display: none !important;
+}
+
+#content-container:has(.tk-page) #content {
+ max-width: none !important;
+ padding: 0 !important;
+}
+
+.tk-page {
+ width: 100%;
+ max-width: 92rem;
+ margin-inline: auto;
+ padding: 0 3rem 5rem; /* px-12 — aligns with nav tabs */
+ box-sizing: border-box;
+}
+
+@media (max-width: 1000px) {
+ .tk-page {
+ padding-inline: 40px;
+ }
+}
+
+@media (max-width: 868px) {
+ .tk-page {
+ padding-inline: 20px;
+ padding-bottom: 2.5rem;
+ }
+}
+
+/* ============================================================
+ Light / dark image switching
+ ============================================================ */
+
+.tk-img-light { display: block !important; }
+.tk-img-dark { display: none !important; }
+.dark .tk-img-light { display: none !important; }
+.dark .tk-img-dark { display: block !important; }
+
+.dark .tk-page {
+ --tk-surface: #0B0B0F;
+}
+
+/* ============================================================
+ Asset placeholders
+ ============================================================ */
+
+.tk-placeholder {
+ background: #f3f4f6;
+ border: 2px dashed #d1d5db;
+ border-radius: 10px;
+ display: flex;
+ flex-direction: column;
+ align-items: center;
+ justify-content: center;
+ gap: 4px;
+ padding: 1.5rem;
+ text-align: center;
+ font-size: 0.75rem;
+ color: #9ca3af;
+ box-sizing: border-box;
+}
+
+.dark .tk-placeholder {
+ background: #1f2937;
+ border-color: #374151;
+ color: #6b7280;
+}
+
+/* ============================================================
+ Section divider
+ ============================================================ */
+
+.section-divider {
+ border: none;
+ border-top: 1px solid #e5e7eb;
+ margin: 0;
+}
+
+.dark .section-divider {
+ border-top-color: rgba(255, 255, 255, 0.06);
+}
+
+/* ============================================================
+ Hero
+ ============================================================ */
+
+.tk-hero {
+ position: relative;
+ overflow: hidden;
+ padding: 2.5rem 0 3rem;
+ min-height: 360px;
+ display: flex;
+ align-items: stretch;
+ justify-content: flex-start;
+ gap: 2.5rem;
+}
+
+.tk-hero-content {
+ flex: 0 1 720px;
+ max-width: 62%;
+ min-width: 0;
+ align-self: flex-start;
+ position: relative;
+ z-index: 2;
+}
+
+.tk-hero-headline {
+ color: var(--Black, #111);
+ font-family: 'ABC Favorit', sans-serif;
+ font-size: 82px;
+ font-style: normal;
+ font-weight: 400;
+ line-height: 95%;
+ letter-spacing: -4.1px;
+ font-synthesis: none;
+ margin: 0 0 1.25rem;
+ max-width: 720px;
+}
+
+.dark .tk-hero-headline {
+ color: #f9fafb;
+}
+
+.tk-hero-body {
+ color: #414146;
+ font-family: Inter, sans-serif;
+ font-size: 18px;
+ font-style: normal;
+ font-weight: 400;
+ line-height: 28px;
+ font-feature-settings: 'ss01' on, 'ss03' on;
+ margin: 0 0 1.5rem;
+ max-width: 720px;
+}
+
+.dark .tk-hero-body {
+ color: #a1a1aa;
+}
+
+/* Shared description / body copy (welcome page, not hero) */
+.tk-build-body,
+.tk-whitepaper-text {
+ color: #414146;
+ font-family: Inter, sans-serif;
+ font-size: 16px;
+ font-style: normal;
+ font-weight: 400;
+ line-height: 28px;
+}
+
+.dark .tk-build-body,
+.dark .tk-whitepaper-text {
+ color: #a1a1aa;
+}
+
+.tk-search-bar {
+ display: flex;
+ align-items: center;
+ gap: 12px;
+ border-radius: 12px;
+ border: 1px solid var(--Black-20, rgba(0, 0, 0, 0.20));
+ background: var(--Black-4, rgba(0, 0, 0, 0.04));
+ padding: 12px 16px;
+ cursor: pointer;
+ max-width: 500px;
+ transition: border-color 0.15s, background 0.15s;
+}
+
+.tk-search-bar:hover {
+ border-color: rgba(0, 0, 0, 0.28);
+ background: rgba(0, 0, 0, 0.06);
+}
+
+.tk-search-icon {
+ flex-shrink: 0;
+ color: #737277;
+}
+
+.tk-search-placeholder {
+ flex: 1;
+ color: #737277;
+ text-align: left;
+ font-family: Inter, sans-serif;
+ font-size: 16px;
+ font-style: normal;
+ font-weight: 400;
+ line-height: 24px;
+}
+
+.dark .tk-search-icon,
+.dark .tk-search-placeholder {
+ color: #a1a1aa;
+}
+
+.dark .tk-search-bar {
+ border-color: rgba(255, 255, 255, 0.20);
+ background: rgba(255, 255, 255, 0.04);
+}
+
+.dark .tk-search-bar:hover {
+ border-color: rgba(255, 255, 255, 0.28);
+ background: rgba(255, 255, 255, 0.06);
+}
+
+.tk-search-kbd {
+ color: #737277;
+ text-align: center;
+ font-family: "SF Pro", -apple-system, BlinkMacSystemFont, sans-serif;
+ font-size: 12px;
+ font-style: normal;
+ font-weight: 590;
+ line-height: 16px;
+ border: none;
+ border-radius: 0;
+ padding: 0;
+ background: transparent;
+}
+
+.dark .tk-search-kbd {
+ color: #a1a1aa;
+ background: transparent;
+}
+
+.tk-hero-illustration {
+ position: relative;
+ flex: 0 0 657px;
+ width: 657px;
+ min-height: 329px;
+ display: flex;
+ align-items: center;
+ justify-content: flex-start;
+ z-index: 1;
+ pointer-events: none;
+ user-select: none;
+}
+
+/* Grid is a direct child of .tk-hero — keep it out of flex flow */
+.tk-hero > .tk-hero-grid {
+ flex: none;
+}
+
+/* Force a fixed pixel width — this locks the height; illustration never shrinks vertically */
+.tk-hero-illustration > * {
+ pointer-events: none;
+ cursor: default;
+}
+
+.tk-hero-grid {
+ position: absolute;
+ top: 0;
+ right: 0;
+ width: 640px;
+ height: 512px;
+ z-index: 0;
+ pointer-events: none;
+}
+
+.tk-hero-grid img {
+ display: block;
+ width: 640px;
+ height: 512px;
+}
+
+.tk-hero-img {
+ position: relative;
+ display: block;
+ width: 657px;
+ height: 329px;
+ flex-shrink: 0;
+ pointer-events: none;
+ border: none;
+}
+
+.tk-hero-img svg {
+ display: block;
+ width: 657px;
+ height: 329px;
+}
+
+/* Hero tablet — Figma 169:4781 (869–1440px): copy left, graphic right, crop at viewport */
+@media (max-width: 1440px) and (min-width: 869px) {
+ .tk-hero {
+ position: relative;
+ flex-direction: row;
+ align-items: flex-start;
+ justify-content: flex-start;
+ gap: 1rem;
+ width: 100vw;
+ max-width: 100vw;
+ margin-left: calc(50% - 50vw);
+ padding: 2.3125rem 0 2.5rem 3rem;
+ min-height: auto;
+ overflow: hidden;
+ box-sizing: border-box;
+ }
+
+ .tk-hero-grid {
+ top: -3.3125rem;
+ right: 0;
+ left: auto;
+ width: 640px;
+ height: 512px;
+ }
+
+ .tk-hero-grid img {
+ width: 640px;
+ height: 512px;
+ max-height: none;
+ object-fit: none;
+ }
+
+ .tk-hero-content {
+ display: flex;
+ flex-direction: column;
+ gap: 24px;
+ flex: 0 0 612px;
+ max-width: 612px;
+ width: 612px;
+ align-self: flex-start;
+ position: relative;
+ z-index: 2;
+ isolation: isolate;
+ }
+
+ .tk-hero-content::before {
+ content: "";
+ position: absolute;
+ z-index: -1;
+ top: 0;
+ right: 0;
+ bottom: 0;
+ left: 0;
+ width: 100%;
+ pointer-events: none;
+ background: linear-gradient(
+ 90deg,
+ #ffffff 0%,
+ #ffffff 75%,
+ rgba(255, 255, 255, 0) 100%
+ );
+ }
+
+ .dark .tk-hero-content::before {
+ background: linear-gradient(
+ 90deg,
+ var(--tk-surface, #0B0B0F) 0%,
+ var(--tk-surface, #0B0B0F) 75%,
+ rgba(11, 11, 15, 0) 100%
+ );
+ }
+
+ .tk-hero-headline {
+ font-size: 74px;
+ letter-spacing: -3.7px;
+ line-height: 0.95;
+ margin: 0;
+ max-width: none;
+ }
+
+ .tk-hero-body {
+ margin: 0;
+ max-width: none;
+ }
+
+ .tk-search-bar {
+ max-width: 437px;
+ }
+
+ .tk-hero-illustration {
+ position: absolute;
+ top: 2.3125rem;
+ right: 0;
+ display: block;
+ flex: none;
+ width: 657px;
+ min-width: 657px;
+ min-height: 328px;
+ margin: 0;
+ overflow: visible;
+ z-index: 1;
+ }
+
+ .tk-hero-img {
+ display: block;
+ width: 657px;
+ max-width: none;
+ height: auto;
+ }
+}
+
+@media (max-width: 1190px) and (min-width: 869px) {
+ .tk-hero-illustration {
+ right: -100px;
+ }
+}
+
+@media (max-width: 1000px) and (min-width: 869px) {
+ .tk-hero {
+ padding-left: 40px;
+ }
+}
+
+/* Tablet — Figma Responsive frame (1000px) */
+@media (max-width: 1000px) {
+ .tk-whitepaper {
+ padding: 20px 40px 0;
+ }
+}
+
+
+/* Mobile — Figma Responsive 169:4327 (≤868px) */
+@media (max-width: 868px) {
+ .tk-hero {
+ flex-direction: column;
+ gap: 0;
+ padding: 2.25rem 0 2.5rem;
+ min-height: auto;
+ overflow: visible;
+ }
+
+ .tk-hero-grid {
+ display: none;
+ }
+
+ .tk-hero-illustration {
+ display: none;
+ }
+
+ .tk-hero-content {
+ display: flex;
+ flex-direction: column;
+ gap: 24px;
+ flex: 1 1 auto;
+ max-width: 100%;
+ width: 100%;
+ isolation: auto;
+ }
+
+ .tk-hero-content::before {
+ display: none;
+ }
+
+ .tk-hero-headline {
+ font-size: 44px;
+ letter-spacing: -2.2px;
+ line-height: 0.95;
+ margin: 0;
+ }
+
+ .tk-hero-body {
+ margin: 0;
+ }
+
+ .tk-search-bar {
+ max-width: none;
+ width: 100%;
+ }
+
+ .tk-build,
+ .tk-solutions-section,
+ .tk-features-section,
+ .tk-whitepaper-section {
+ margin: 2.5rem 0;
+ }
+}
+
+/* ============================================================
+ Section headings
+ ============================================================ */
+
+.tk-section-heading {
+ font-family: Inter, sans-serif;
+ font-size: 30px;
+ font-weight: 700;
+ letter-spacing: -0.75px;
+ line-height: 1.2;
+ margin: 0 0 1.25rem;
+ color: #1a191e;
+}
+
+.dark .tk-section-heading { color: #f9fafb; }
+
+/* ============================================================
+ Build with Turnkey
+ ============================================================ */
+
+/* Build with Turnkey — shared */
+.tk-build {
+ display: grid;
+ grid-template-columns: 1fr;
+ gap: 28px;
+ align-items: start;
+ margin: 52px 0;
+}
+
+.tk-build-intro {
+ display: contents;
+}
+
+.tk-build-copy {
+ display: flex;
+ flex-direction: column;
+ gap: 28px;
+ grid-column: 1;
+ grid-row: 1;
+}
+
+.tk-build-visual {
+ display: flex;
+ flex-direction: row;
+ align-items: center;
+ justify-content: flex-start;
+ gap: 40px; /* Figma: 40px between cube and selector panel */
+ grid-column: 1;
+ grid-row: 2;
+ width: 100%;
+ justify-self: start;
+}
+
+.tk-build-links {
+ grid-column: 1;
+ grid-row: 3;
+}
+
+.tk-build-selectors {
+ flex: 0 0 auto;
+ min-width: 0;
+ max-width: none;
+ justify-content: flex-start;
+}
+
+.tk-selector-list {
+ width: 100%;
+ max-width: 100%;
+}
+
+/* Tablet / small desktop — center cube + selectors row */
+@media (min-width: 869px) and (max-width: 1199px) {
+ .tk-build-visual {
+ justify-content: center;
+ justify-self: center;
+ width: fit-content;
+ max-width: 100%;
+ margin-inline: auto;
+ }
+}
+
+/* Desktop — Figma: intro | 40px | cube | selectors (no stretched gutter) */
+@media (min-width: 1200px) {
+ .tk-build {
+ display: grid;
+ grid-template-columns: minmax(0, 558px) auto;
+ width: 100%;
+ gap: 40px;
+ align-items: center;
+ justify-items: start;
+ }
+
+ .tk-build-intro {
+ display: flex;
+ flex-direction: column;
+ gap: 28px;
+ min-width: 0;
+ max-width: 558px;
+ }
+
+ .tk-build-copy {
+ grid-column: unset;
+ grid-row: unset;
+ max-width: none;
+ }
+
+ .tk-build-links {
+ grid-column: unset;
+ grid-row: unset;
+ }
+
+ .tk-build-visual {
+ display: flex;
+ flex-direction: row;
+ align-items: center;
+ justify-content: flex-start;
+ gap: 40px;
+ width: auto;
+ min-width: 0;
+ grid-column: unset;
+ grid-row: unset;
+ justify-self: start;
+ }
+
+ .tk-build-selectors {
+ flex: 0 0 auto;
+ min-width: auto;
+ max-width: none;
+ justify-content: flex-start;
+ }
+
+ .tk-selector-list {
+ width: max-content;
+ max-width: 100%;
+ }
+}
+
+.tk-build-heading {
+ font-family: Inter, sans-serif;
+ font-size: 30px;
+ font-weight: 700;
+ letter-spacing: -0.75px;
+ line-height: normal;
+ margin: 0;
+ color: #1a191e;
+}
+
+.dark .tk-build-heading { color: #f9fafb; }
+
+.tk-build-body {
+ margin: 0;
+}
+
+.tk-build-links {
+ display: flex;
+ flex-direction: row;
+ gap: 40px;
+ flex-wrap: wrap;
+}
+
+.tk-build-link {
+ display: inline-flex;
+ align-items: center;
+ gap: 7px;
+ color: #4C48FF;
+ font-weight: 500;
+ text-decoration: none;
+ font-size: 0.875rem;
+ transition: opacity 0.15s;
+}
+
+.tk-build-link-icon {
+ flex-shrink: 0;
+}
+
+.dark .tk-build-link { color: #5B68FF; }
+.tk-build-link:hover { opacity: 0.75; }
+
+/* Cube — Figma Boxes A/B/C (149×170) */
+.tk-build-cube {
+ width: 149px;
+ flex-shrink: 0;
+ margin: 0;
+ padding: 0;
+ align-self: center;
+}
+
+.tk-cube-wrapper {
+ position: relative;
+ width: 149px;
+ height: 170px;
+ margin: 0;
+ padding: 0;
+ pointer-events: none;
+ user-select: none;
+}
+
+.tk-plane-img {
+ position: absolute;
+ top: 0;
+ left: 0;
+ width: 100%;
+ height: 100%;
+ object-fit: contain;
+ opacity: 0;
+ visibility: hidden;
+ transition: none;
+ pointer-events: none;
+ cursor: default;
+}
+
+/* Selected row → swap plane (instant, no crossfade) */
+.tk-build[data-selected="a"] .tk-plane-img[data-plane="a"],
+.tk-build[data-selected="b"] .tk-plane-img[data-plane="b"],
+.tk-build[data-selected="c"] .tk-plane-img[data-plane="c"] {
+ opacity: 1;
+ visibility: visible;
+}
+
+/* Selectors panel — Figma 249:1834 */
+.tk-build-selectors {
+ display: flex;
+ flex-direction: row;
+ align-items: center;
+ gap: 17px; /* Figma: list starts 33px, connectors end ~16px → ~17px */
+ width: max-content;
+ max-width: 100%;
+ flex-shrink: 0;
+ overflow: visible;
+}
+
+.tk-build-connectors {
+ position: relative;
+ flex-shrink: 0;
+ width: 40px;
+ height: 120px; /* Figma: 3 × 40px rows */
+ margin-left: -24px; /* Figma: connectors overlap cube by ~24px */
+ pointer-events: none;
+}
+
+.tk-connector-line {
+ position: absolute;
+ left: 0;
+ width: 40px;
+ height: 0;
+}
+
+.tk-connector-line--a { top: 20px; }
+.tk-connector-line--b { top: 60px; }
+.tk-connector-line--c { top: 100px; }
+
+.tk-connector-line::after {
+ content: "";
+ position: absolute;
+ left: 0;
+ right: 0;
+ top: 0;
+ height: 1px;
+ background: rgba(0, 0, 0, 0.2);
+ transition: background 0.15s;
+}
+
+.dark .tk-connector-line::after {
+ background: rgba(255, 255, 255, 0.2);
+}
+
+.tk-build[data-selected="a"] .tk-connector-line--a::after,
+.tk-build[data-selected="b"] .tk-connector-line--b::after,
+.tk-build[data-selected="c"] .tk-connector-line--c::after {
+ background: #4C48FF;
+}
+
+.dark .tk-build[data-selected="a"] .tk-connector-line--a::after,
+.dark .tk-build[data-selected="b"] .tk-connector-line--b::after,
+.dark .tk-build[data-selected="c"] .tk-connector-line--c::after {
+ background: #5B68FF;
+}
+
+.tk-selector-list {
+ position: relative;
+ flex-shrink: 0;
+ display: grid;
+ grid-template-columns: 1fr;
+ gap: 0; /* Figma: rows stack flush (40px each) */
+ width: max-content;
+ max-width: 100%;
+}
+
+.tk-selector-row {
+ position: relative;
+ display: flex;
+ align-items: center;
+ gap: 12px;
+ box-sizing: border-box;
+ width: 100%;
+ height: 40px;
+ min-height: 40px;
+ padding: 8px 36px 8px 12px; /* Figma: pl-12 pr-8 py-8 + room for chevron */
+ white-space: nowrap;
+ text-decoration: none;
+ color: inherit;
+ border-radius: 8px;
+ border: none;
+ transition: background 0.15s, color 0.15s;
+}
+
+.tk-build[data-selected="a"] #tk-row-a,
+.tk-build[data-selected="b"] #tk-row-b,
+.tk-build[data-selected="c"] #tk-row-c {
+ background: rgba(76, 72, 255, 0.12);
+}
+
+.dark .tk-build[data-selected="a"] #tk-row-a,
+.dark .tk-build[data-selected="b"] #tk-row-b,
+.dark .tk-build[data-selected="c"] #tk-row-c {
+ background: rgba(91, 104, 255, 0.12);
+}
+
+.tk-selector-icon {
+ width: 24px;
+ height: 24px;
+ display: flex;
+ align-items: center;
+ justify-content: center;
+ flex-shrink: 0;
+ color: #28282c;
+ opacity: 0.5;
+ background: none;
+ border-radius: 0;
+ transition: color 0.15s, opacity 0.15s;
+}
+
+.tk-selector-icon svg {
+ width: 24px;
+ height: 24px;
+}
+
+.tk-selector-icon svg path,
+.tk-selector-icon svg g path {
+ stroke-width: 1.5;
+}
+
+.dark .tk-selector-icon { color: #d1d5db; }
+
+.tk-selector-label {
+ font-family: Inter, sans-serif;
+ font-size: 14px;
+ font-weight: 600;
+ line-height: normal;
+ color: #28282c;
+ flex-shrink: 0;
+ transition: color 0.15s;
+}
+
+.dark .tk-selector-label { color: #f3f4f6; }
+
+.tk-build[data-selected="a"] #tk-row-a .tk-selector-label,
+.tk-build[data-selected="b"] #tk-row-b .tk-selector-label,
+.tk-build[data-selected="c"] #tk-row-c .tk-selector-label {
+ color: #4C48FF;
+}
+
+.dark .tk-build[data-selected="a"] #tk-row-a .tk-selector-label,
+.dark .tk-build[data-selected="b"] #tk-row-b .tk-selector-label,
+.dark .tk-build[data-selected="c"] #tk-row-c .tk-selector-label {
+ color: #5B68FF;
+}
+
+.tk-build[data-selected="a"] #tk-row-a .tk-selector-icon,
+.tk-build[data-selected="b"] #tk-row-b .tk-selector-icon,
+.tk-build[data-selected="c"] #tk-row-c .tk-selector-icon {
+ opacity: 1;
+ color: #4C48FF;
+}
+
+.dark .tk-build[data-selected="a"] #tk-row-a .tk-selector-icon,
+.dark .tk-build[data-selected="b"] #tk-row-b .tk-selector-icon,
+.dark .tk-build[data-selected="c"] #tk-row-c .tk-selector-icon {
+ color: #5B68FF;
+}
+
+.tk-selector-desc {
+ font-family: Inter, sans-serif;
+ font-size: 14px;
+ font-weight: 400;
+ line-height: 1.48;
+ color: #505454;
+ flex-shrink: 1;
+ min-width: 0;
+}
+
+.dark .tk-selector-desc { color: #9ca3af; }
+
+.tk-selector-chevron {
+ position: absolute;
+ right: 8px;
+ top: 50%;
+ display: flex;
+ align-items: center;
+ justify-content: center;
+ width: 20px;
+ height: 20px;
+ transform: translateY(-50%);
+ opacity: 0;
+ color: #4C48FF;
+ pointer-events: none;
+ transition: opacity 0.2s ease;
+}
+
+.dark .tk-selector-chevron {
+ color: #5B68FF;
+}
+
+.tk-selector-chevron svg {
+ width: 20px;
+ height: 20px;
+}
+
+.tk-selector-chevron svg path {
+ stroke-width: 1.5;
+}
+
+.tk-build[data-selected="a"] #tk-row-a .tk-selector-chevron,
+.tk-build[data-selected="b"] #tk-row-b .tk-selector-chevron,
+.tk-build[data-selected="c"] #tk-row-c .tk-selector-chevron,
+.tk-selector-row:hover .tk-selector-chevron {
+ opacity: 1;
+}
+
+@media (max-width: 868px) {
+ .tk-build {
+ grid-template-columns: 1fr;
+ align-items: start;
+ gap: 28px;
+ }
+
+ .tk-build-intro {
+ display: contents;
+ }
+
+ .tk-build-copy {
+ grid-column: 1 / -1;
+ grid-row: 1;
+ }
+
+ .tk-build-links {
+ grid-column: 1 / -1;
+ grid-row: 2;
+ gap: 40px;
+ }
+
+ .tk-build-visual {
+ grid-column: 1 / -1;
+ grid-row: 3;
+ flex-direction: column;
+ gap: 16px;
+ width: 100%;
+ align-items: center;
+ padding: 0;
+ }
+
+ .tk-build-cube {
+ width: 100%;
+ max-width: 149px;
+ margin: 0 auto;
+ }
+
+ .tk-cube-wrapper {
+ width: 149px;
+ height: 170px;
+ margin: 0 auto;
+ }
+
+ /* Mobile default: Boxes A (Solutions); desktop keeps data-selected="c" */
+ .tk-build[data-selected="c"]:not([data-user-picked]) .tk-plane-img[data-plane="c"] {
+ opacity: 0;
+ visibility: hidden;
+ }
+
+ .tk-build[data-selected="c"]:not([data-user-picked]) .tk-plane-img[data-plane="a"] {
+ opacity: 1;
+ visibility: visible;
+ }
+
+ .tk-build-selectors {
+ width: 100%;
+ max-width: 100%;
+ justify-content: stretch;
+ }
+
+ .tk-build-connectors {
+ display: none;
+ }
+
+ .tk-selector-list {
+ width: 100%;
+ max-width: 100%;
+ gap: 0;
+ }
+
+ .tk-selector-row {
+ display: grid;
+ grid-template-columns: 24px minmax(0, 1fr) 20px;
+ grid-template-rows: auto auto;
+ column-gap: 12px;
+ row-gap: 0;
+ align-items: center;
+ width: 100%;
+ max-width: 100%;
+ min-height: 54px;
+ padding: 8px;
+ white-space: normal;
+ background: transparent !important;
+ border-radius: 0;
+ }
+
+ .tk-selector-row + .tk-selector-row {
+ border-top: 1px solid rgba(0, 0, 0, 0.12);
+ margin-top: 4px;
+ }
+
+ .dark .tk-selector-row + .tk-selector-row {
+ border-top-color: rgba(255, 255, 255, 0.06);
+ }
+
+ .tk-selector-icon {
+ grid-column: 1;
+ grid-row: 1 / 3;
+ align-self: center;
+ opacity: 1;
+ color: #4C48FF;
+ }
+
+ .dark .tk-selector-icon {
+ color: #5B68FF;
+ }
+
+ .tk-selector-label {
+ grid-column: 2;
+ grid-row: 1;
+ font-weight: 500;
+ color: #4C48FF;
+ }
+
+ .dark .tk-selector-label {
+ color: #5B68FF;
+ }
+
+ .tk-selector-desc {
+ grid-column: 2;
+ grid-row: 2;
+ white-space: normal;
+ overflow: visible;
+ text-overflow: unset;
+ }
+
+ .tk-selector-chevron {
+ grid-column: 3;
+ grid-row: 1 / 3;
+ position: static;
+ transform: none;
+ opacity: 1;
+ }
+}
+
+/* ============================================================
+ Solution cards
+ ============================================================ */
+
+.tk-solutions-section {
+ display: flex;
+ flex-direction: column;
+ gap: 28px;
+ margin: 52px 0;
+}
+
+.tk-solutions-section .tk-solution-card {
+ display: grid !important;
+}
+
+.tk-solutions-section .tk-section-heading {
+ margin: 0;
+}
+
+.tk-solutions-grid {
+ display: grid;
+ grid-template-columns: repeat(3, 1fr);
+ column-gap: 24px;
+ row-gap: 20px;
+ width: 100%;
+}
+
+.tk-solution-card {
+ grid-row: span 3;
+ display: grid;
+ grid-template-rows: subgrid;
+ box-sizing: border-box;
+ padding: 20px 32px 36px;
+ background: rgba(0, 0, 0, 0.02);
+ border: 1px solid rgba(13, 12, 17, 0.1);
+ border-radius: 16px;
+}
+
+.tk-solution-copy {
+ display: flex;
+ flex-direction: column;
+ gap: 8px;
+ min-width: 0;
+}
+
+.dark .tk-solution-card {
+ background: rgba(255, 255, 255, 0.02);
+ border-color: rgba(255, 255, 255, 0.12);
+}
+
+.tk-solution-thumbnail {
+ width: 120px;
+ height: 120px;
+ flex-shrink: 0;
+}
+
+.tk-solution-thumbnail img {
+ display: block;
+ width: 100%;
+ height: 100%;
+ object-fit: contain;
+}
+
+.tk-solution-copy .tk-solution-title,
+.tk-solution-card > .tk-solution-title-row {
+ min-width: 0;
+}
+
+.tk-solution-title-row {
+ display: inline-flex;
+ align-items: center;
+ gap: 12px;
+ flex-wrap: nowrap;
+ width: fit-content;
+ max-width: 100%;
+}
+
+.tk-solution-title-row .tk-solution-title {
+ width: auto;
+ max-width: none;
+}
+
+.tk-solution-title-long {
+ display: inline;
+}
+
+.tk-solution-title-short {
display: none;
}
-#hidden-content-simple[data-open="true"] {
- display: block; /* Or inline, inline-block, etc., as needed */
+.tk-solution-title {
+ font-family: Inter, sans-serif;
+ font-size: 24px;
+ font-weight: 600;
+ letter-spacing: -0.6px;
+ line-height: 32px;
+ margin: 0;
+ color: #111827;
+ text-decoration: none;
+}
+
+.dark .tk-solution-title { color: #f9fafb; }
+
+.tk-solution-desc {
+ margin: 0;
+ font-family: Inter, sans-serif;
+ font-size: 14px;
+ font-weight: 400;
+ line-height: 1.48;
+ color: #414146;
+ min-width: 0;
+}
+
+.dark .tk-solution-desc { color: #a1a1aa; }
+
+.tk-solution-links {
+ display: flex;
+ flex-direction: column;
+ gap: 16px;
+ align-items: flex-start;
+ min-width: 0;
+ border-top: 1px solid rgba(0, 0, 0, 0.12);
+ padding-top: 20px;
+}
+
+.dark .tk-solution-links {
+ border-top-color: rgba(255, 255, 255, 0.06);
+}
+
+.tk-solution-link {
+ text-decoration: none;
+ font-family: Inter, sans-serif;
+ font-size: 14px;
+ font-weight: 500;
+ color: #4C48FF;
+ transition: opacity 0.15s;
+}
+
+.tk-solution-link:hover { opacity: 0.75; color: #4C48FF; }
+.dark .tk-solution-link { color: #5B68FF; }
+.dark .tk-solution-link:hover { opacity: 0.75; }
+
+@media (max-width: 768px) {
+ .tk-solutions-grid {
+ grid-template-columns: 1fr;
+ }
+}
+
+/* ============================================================
+ Features section
+ ============================================================ */
+
+.tk-features-section {
+ display: flex;
+ flex-direction: column;
+ gap: 28px;
+ margin: 52px 0;
+}
+
+.tk-features-section .tk-section-heading {
+ margin: 0;
+}
+
+.tk-features-grid {
+ display: grid;
+ grid-template-columns: repeat(3, 1fr);
+ gap: 40px;
+ width: 100%;
+}
+
+.tk-feature-column {
+ display: flex;
+ flex-direction: column;
+ gap: 12px;
+ min-width: 0;
+}
+
+.tk-feature-column-heading {
+ font-family: Inter, sans-serif;
+ font-size: 18px;
+ font-weight: 600;
+ line-height: 32px;
+ color: #111827;
+ margin: 0;
+}
+
+.dark .tk-feature-column-heading {
+ color: #f9fafb;
+}
+
+.tk-feature-items {
+ display: flex;
+ flex-direction: column;
+ gap: 8px;
+ width: 100%;
+}
+
+.tk-feature-divider {
+ border: none;
+ height: 1px;
+ margin: 0;
+ background: rgba(0, 0, 0, 0.12);
+}
+
+.dark .tk-feature-divider {
+ background: rgba(255, 255, 255, 0.06);
+}
+
+.tk-feature-row {
+ display: flex;
+ align-items: center;
+ gap: 12px;
+ padding: 4px 0;
+ text-decoration: none;
+ color: #000000;
+ font-family: Inter, sans-serif;
+ font-size: 16px;
+ font-weight: 500;
+ line-height: normal;
+ transition: color 0.12s ease;
+}
+
+.dark .tk-feature-row {
+ color: #f3f4f6;
+}
+
+.tk-feature-row:hover,
+.tk-feature-row:focus-visible {
+ color: #4C48FF;
+}
+
+.dark .tk-feature-row:hover,
+.dark .tk-feature-row:focus-visible {
+ color: #5B68FF;
+}
+
+.tk-feature-icon-circle {
+ display: flex;
+ align-items: center;
+ justify-content: center;
+ flex-shrink: 0;
+ padding: 6px;
+ border-radius: 9999px;
+ background: rgba(0, 0, 0, 0.04);
+ border: 1px solid rgba(0, 0, 0, 0.12);
+ color: #000000;
+ transition: background 0.12s ease, border-color 0.12s ease, color 0.12s ease;
+}
+
+.dark .tk-feature-icon-circle {
+ background: rgba(255, 255, 255, 0.04);
+ border-color: rgba(255, 255, 255, 0.12);
+ color: #f3f4f6;
+}
+
+.tk-feature-row:hover .tk-feature-icon-circle,
+.tk-feature-row:focus-visible .tk-feature-icon-circle {
+ background: #f1f3ff;
+ border-color: #c9ceff;
+ color: #4C48FF;
+}
+
+.dark .tk-feature-row:hover .tk-feature-icon-circle,
+.dark .tk-feature-row:focus-visible .tk-feature-icon-circle {
+ background: rgba(91, 104, 255, 0.15);
+ border-color: rgba(91, 104, 255, 0.35);
+ color: #5B68FF;
+}
+
+.tk-feature-icon-circle svg,
+.tk-feature-icon-circle .tk-feature-icon-img {
+ width: 20px;
+ height: 20px;
+ display: block;
+ flex-shrink: 0;
+ opacity: 0.5;
+ transition: opacity 0.12s ease;
+}
+
+.tk-feature-row:hover .tk-feature-icon-circle svg,
+.tk-feature-row:focus-visible .tk-feature-icon-circle svg,
+.tk-feature-row:hover .tk-feature-icon-circle .tk-feature-icon-img,
+.tk-feature-row:focus-visible .tk-feature-icon-circle .tk-feature-icon-img {
+ opacity: 1;
+}
+
+.tk-feature-icon-img {
+ background-color: currentColor;
+ mask-repeat: no-repeat;
+ mask-position: center;
+ mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+ -webkit-mask-position: center;
+ -webkit-mask-size: contain;
+}
+
+.tk-feature-icon-img--wallet-embedded {
+ mask-image: url('/images/icons/wallet-embedded.svg');
+ -webkit-mask-image: url('/images/icons/wallet-embedded.svg');
+}
+
+.tk-feature-icon-img--fuel {
+ mask-image: url('/images/icons/fuel.svg');
+ -webkit-mask-image: url('/images/icons/fuel.svg');
+}
+
+.tk-feature-icon-circle svg path,
+.tk-feature-icon-circle svg g path,
+.tk-feature-icon-circle svg line,
+.tk-feature-icon-circle svg circle,
+.tk-feature-icon-circle svg rect {
+ stroke-width: 1.5px;
+ vector-effect: non-scaling-stroke;
+}
+
+.tk-feature-label {
+ flex: 1;
+ min-width: 0;
+}
+
+.tk-feature-row::after {
+ content: '';
+ width: 20px;
+ height: 20px;
+ flex-shrink: 0;
+ opacity: 0;
+ transition: opacity 0.12s ease;
+ background-color: #4C48FF;
+ mask-image: url('/images/icons/chevron-right.svg');
+ mask-repeat: no-repeat;
+ mask-position: center;
+ mask-size: contain;
+ -webkit-mask-image: url('/images/icons/chevron-right.svg');
+ -webkit-mask-repeat: no-repeat;
+ -webkit-mask-position: center;
+ -webkit-mask-size: contain;
+}
+
+.dark .tk-feature-row::after {
+ background-color: #5B68FF;
+}
+
+.tk-feature-row:hover::after,
+.tk-feature-row:focus-visible::after {
+ opacity: 1;
+}
+
+@media (max-width: 868px) {
+ .tk-features-grid {
+ grid-template-columns: 1fr;
+ gap: 40px;
+ }
+
+ .tk-feature-row--chevron::after {
+ opacity: 1;
+ }
+}
+
+/* ============================================================
+ Whitepaper CTA
+ ============================================================ */
+
+.tk-whitepaper-section {
+ margin: 52px 0;
+}
+
+.tk-whitepaper {
+ position: relative;
+ display: flex;
+ align-items: flex-start;
+ justify-content: center;
+ padding: 20px 48px 0;
+ background: rgba(0, 0, 0, 0.02);
+ border: 1px solid rgba(13, 12, 17, 0.1);
+ border-radius: 16px;
+ overflow: hidden;
+}
+
+.dark .tk-whitepaper {
+ background: rgba(255, 255, 255, 0.02);
+ border-color: rgba(255, 255, 255, 0.1);
+}
+
+.tk-whitepaper-inner {
+ display: flex;
+ gap: 40px;
+ align-items: flex-start;
+ width: auto;
+ max-width: 100%;
+ box-sizing: border-box;
+ padding: 0;
+ min-height: 132px;
+}
+
+.tk-whitepaper-thumb-wrap {
+ position: relative;
+ flex-shrink: 0;
+ align-self: flex-end;
+ width: 121px;
+ height: 132px;
+ overflow: hidden;
+ box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
+}
+
+.tk-whitepaper-thumb {
+ position: absolute;
+ top: 0;
+ left: -46.26%;
+ height: 100%;
+ width: 192.52%;
+ max-width: none;
+ display: block;
+ pointer-events: none;
+}
+
+.tk-whitepaper-content {
+ display: flex;
+ flex-direction: column;
+ gap: 12px;
+ align-items: flex-start;
+ align-self: flex-start;
+ padding-top: 12px;
+ padding-bottom: 0;
+ min-width: 0;
+ max-width: 476px;
+}
+
+.tk-whitepaper-text {
+ margin: 0;
+ max-width: 476px;
+}
+
+.tk-whitepaper-link {
+ display: inline-flex;
+ align-items: center;
+ gap: 8px;
+ color: #4C48FF;
+ font-family: Inter, sans-serif;
+ font-size: 14px;
+ font-weight: 500;
+ line-height: normal;
+ text-decoration: none;
+ transition: opacity 0.15s;
+ white-space: nowrap;
+}
+
+.tk-whitepaper-link-icon {
+ display: flex;
+ flex-shrink: 0;
+ width: 20px;
+ height: 20px;
+ color: #4C48FF;
+}
+
+.tk-whitepaper-link-icon svg {
+ width: 20px;
+ height: 20px;
+ display: block;
+}
+
+.tk-whitepaper-link-icon svg path {
+ stroke-width: 1.5px;
+ vector-effect: non-scaling-stroke;
+}
+
+.dark .tk-whitepaper-link,
+.dark .tk-whitepaper-link-icon {
+ color: #5B68FF;
+}
+
+.tk-whitepaper-link:hover {
+ opacity: 0.75;
+}
+
+@media (max-width: 868px) {
+ .tk-whitepaper {
+ justify-content: flex-start;
+ padding: 0;
+ }
+
+ .tk-whitepaper-thumb-wrap {
+ position: absolute;
+ left: 24px;
+ bottom: 0;
+ }
+
+ .tk-whitepaper-inner {
+ flex-direction: column;
+ align-items: flex-start;
+ gap: 0;
+ width: 100%;
+ padding: 20px 24px 132px;
+ }
+
+ .tk-whitepaper-content {
+ padding-top: 12px;
+ padding-bottom: 0;
+ margin-bottom: 24px;
+ align-items: flex-start;
+ align-self: stretch;
+ text-align: left;
+ width: 100%;
+ }
+
+ .tk-whitepaper-text {
+ max-width: none;
+ }
+}
+
+/* ============================================================
+ Beta badge
+ ============================================================ */
+
+.tk-badge {
+ font-family: Inter, sans-serif;
+ font-size: 10px;
+ font-weight: 500;
+ line-height: normal;
+ background: #ede9fe;
+ color: #4C48FF;
+ border-radius: 4px;
+ padding: 2px 6px;
+ flex-shrink: 0;
+}
+
+.dark .tk-badge {
+ background: rgba(91, 104, 255, 0.2);
+ color: #5B68FF;
+}
+
+/* ============================================================
+ Feature & Solution cards (Next steps, etc.)
+ ============================================================ */
+
+.tk-card-icon-wrap {
+ display: flex;
+ align-items: center;
+ justify-content: center;
+ flex-shrink: 0;
+ width: 44px;
+ height: 44px;
+ border-radius: 9999px;
+ border: 1px solid rgba(0, 0, 0, 0.16);
+ background: #ffffff;
+ box-sizing: border-box;
+}
+
+.dark .tk-card-icon-wrap {
+ background: transparent;
+ border-color: rgba(255, 255, 255, 0.16);
+}
+
+.tk-card-icon {
+ display: block;
+ flex-shrink: 0;
+ width: 24px;
+ height: 25px;
+ background-color: #505454;
+ mask-size: contain;
+ mask-repeat: no-repeat;
+ mask-position: center;
+ -webkit-mask-size: contain;
+ -webkit-mask-repeat: no-repeat;
+ -webkit-mask-position: center;
+}
+
+.dark .tk-card-icon {
+ background-color: #ffffff;
+}
+
+.tk-card-row {
+ display: flex;
+ align-items: flex-start;
+ gap: 16px;
+}
+
+.tk-network-cards .tk-card-row {
+ align-items: center;
+}
+
+.tk-card-network-logo {
+ display: block;
+ width: 24px;
+ height: 24px;
+ object-fit: contain;
+}
+
+.dark .tk-network-cards .tk-card-network-logo[src$="cosmos.svg"],
+.dark .tk-network-cards .tk-card-network-logo[src$="aptos.svg"],
+.dark .tk-network-cards .tk-card-network-logo[src$="tempo.svg"],
+.dark .tk-network-cards .tk-card-network-logo[src$="iota.svg"] {
+ filter: brightness(0) invert(1);
+}
+
+.tk-card-icon-img {
+ display: block;
+ flex-shrink: 0;
+ width: 44px;
+ height: 44px;
+}
+
+/* Networks overview — wide tier table should scroll horizontally without breaking layout */
+#content [data-table-wrapper="true"] {
+ width: 100% !important;
+ max-width: 100% !important;
+ margin-inline: 0 !important;
+ contain: none !important;
}
diff --git a/wallets/export-wallets.mdx b/wallets/export-wallets.mdx
deleted file mode 100644
index 8fa7b5c7..00000000
--- a/wallets/export-wallets.mdx
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: "Export wallets and keys"
-description: "Turnkey's export functionality allows your end users to backup or transfer a [Wallet](/concepts/wallets) by securely viewing the wallet's [mnemonic phrase](https://learnmeabitcoin.com/technical/mnemonic), a [Wallet Account](/concepts/wallets#accounts) or a raw [Private Key](/concepts/wallets#private-keys). We engineered this feature to ensure that the user can export their mnemonic or private key without exposing it to Turnkey or your application."
-mode: "wide"
----
-
-The process of exporting wallets, wallet accounts or private keys from Turnkey is broken up into two primary steps:
-
-
+
+{/* ── HERO ─────────────────────────────────────────────────────────────── */}
+
+
+ +{/* ── BUILD WITH TURNKEY ───────────────────────────────────────────────── */} + +
+ +{/* ── SOLUTIONS ────────────────────────────────────────────────────────── */} + +
+ +{/* ── FEATURES ─────────────────────────────────────────────────────────── */} + +
+ +
+
+
+
+ 
+ 
+
+
+
+
+
+ Secure, flexible,
+
+
+
+ Secure, flexible,
+
+ and scalable wallet infrastructure
+
+ + Turnkey is infrastructure for generating wallets and keys, signing transactions, and + controlling who can use them, when, and how. Private keys are secured in hardware-isolated + enclaves and never exposed — not even to Turnkey. +
+ {
+ if (typeof window !== "undefined") {
+ document.dispatchEvent(
+ new KeyboardEvent("keydown", { key: "k", metaKey: true, bubbles: true }),
+ );
+ }
+ }}
+ >
+
+ Search...
+ ⌘K
+
+
+ 
+ 
+
+
+
+ + +{/* ── BUILD WITH TURNKEY ───────────────────────────────────────────────── */} + +
+
+
+
+
+
+
+
+
+
+Build with Turnkey
++ Build at whichever level best meets your needs. Start with Solutions for common patterns, go + deeper with our SDKs for more control, or reach all the way down to the API for complete + flexibility. The full stack is always available. +
+
+
+
+
+
+
+
+ 
+ 
+ 
+ 
+ 
+ 
+
+
+
+
+
+
+
+
+
+
+
+ { const el = e.currentTarget.closest('.tk-build'); el?.setAttribute('data-selected', 'a'); el?.setAttribute('data-user-picked', 'true'); }} onFocus={(e) => { const el = e.currentTarget.closest('.tk-build'); el?.setAttribute('data-selected', 'a'); el?.setAttribute('data-user-picked', 'true'); }} onTouchStart={(e) => { const el = e.currentTarget.closest('.tk-build'); el?.setAttribute('data-selected', 'a'); el?.setAttribute('data-user-picked', 'true'); }}>
+
+ Solutions
+ Pre-built patterns for common use cases
+
+
+ { const el = e.currentTarget.closest('.tk-build'); el?.setAttribute('data-selected', 'b'); el?.setAttribute('data-user-picked', 'true'); }} onFocus={(e) => { const el = e.currentTarget.closest('.tk-build'); el?.setAttribute('data-selected', 'b'); el?.setAttribute('data-user-picked', 'true'); }} onTouchStart={(e) => { const el = e.currentTarget.closest('.tk-build'); el?.setAttribute('data-selected', 'b'); el?.setAttribute('data-user-picked', 'true'); }}>
+
+ SDKs
+ TypeScript, React, React Native, and more
+
+
+ { const el = e.currentTarget.closest('.tk-build'); el?.setAttribute('data-selected', 'c'); el?.setAttribute('data-user-picked', 'true'); }} onFocus={(e) => { const el = e.currentTarget.closest('.tk-build'); el?.setAttribute('data-selected', 'c'); el?.setAttribute('data-user-picked', 'true'); }} onTouchStart={(e) => { const el = e.currentTarget.closest('.tk-build'); el?.setAttribute('data-selected', 'c'); el?.setAttribute('data-user-picked', 'true'); }}>
+
+ API
+ REST API for controlling every operation
+
+
+
+ + +{/* ── SOLUTIONS ────────────────────────────────────────────────────────── */} + +
+
+
+Explore Turnkey Solutions
+ +
+
+
+
+
+
+
+
+ 
+
+
+
+
+ Embedded Wallets
+
+
+
++ Build wallets directly into your app. Users authenticate with email, passkeys, or social login. + You control the experience. +
+
+
+
+
+ 
+
+
+
+
+ Company Wallets
+
+
+
++ Automate your onchain operations with wallets, keys and programmable controls purpose built for + scale. +
+
+
+
+
+ 
+
+
+
+
+ Key Management
+
+
+
++ Enterprise-grade security for your most sensitive keys — hardware-backed with programmable + access controls. +
++ +{/* ── FEATURES ─────────────────────────────────────────────────────────── */} + +
+
+
+{/* ── WHITEPAPER CTA ───────────────────────────────────────────────────── */}
+
+Explore our features
+ +
+
+
+
+
+
+ Manage wallets & keys
+ +
+
+
+ Control access
+ +
+
+
+ Transact programmatically
+ ++ +
+
+
+
+
+
+
+
+ 
+
+
+
+
+ + Read our whitepaper for an in-depth look at Turnkey's security model and verifiable key + management infrastructure. +
+ + + Read the Turnkey Whitepaper + +