-
-Our docs site is small, so each crawl is quick (~30-60s).
-
-### Vercel
-
-Each push to Github will trigger a Vercel build:
-
-
-
-This is a convenient way to view changes, add feedback, and collaborate overall. Any build can also be promoted to production, if need be.
+The dashboard provides analytics, deployment status, and other management features for our documentation.
## Build & Code Generation
@@ -79,3 +52,20 @@ We provide the following Make targets to generate API reference content:
- `make tags`: Generate the endpoint-tags MDX snippet at `snippets/data/endpoint-tags.mdx`.
These commands require Node.js and `ts-node`.
+
+---
+
+**Shared Snippets Usage Guidelines**
+
+The docs in this repository utilize shared MDX snippets to ensure consistency and adherence to DRY principles across duplicate pages. When identical content is required in multiple locations, each duplicate page imports a shared snippet from the `/snippets/shared/` folder. This method minimizes maintenance overhead by centralizing content updates.
+
+**Important:** Always update the shared MDX file rather than modifying individual duplicate pages. This guarantees that any change propagates throughout all references.
+
+| Duplicate Page Path | Shared MDX File |
+| ------------------------------------------------------------ | -------------------------------------- |
+| `concepts/policies/overview.mdx` | `/snippets/shared/policy-engine.mdx` |
+| `products/embedded-wallets/features/policy-engine.mdx` | `/snippets/shared/policy-engine.mdx` |
+| `products/transaction-automation/features/export-wallets.mdx` | `/snippets/shared/export-wallets.mdx` |
+| `products/transaction-automation/features/import-wallets.mdx` | `/snippets/shared/import-wallets.mdx` |
+
+*Note: Duplicate pages must reside in separate file paths as required by `docs.json`. Mintlify restricts pages with identical content from sharing the same path to ensure correct sidebar behavior.*
diff --git a/authentication/email.mdx b/authentication/email.mdx
index de790eb1..e4df7ef1 100644
--- a/authentication/email.mdx
+++ b/authentication/email.mdx
@@ -1,7 +1,6 @@
---
-title: "Overview"
+title: "Email Auth & Recovery"
description: "Email Authentication enables users to authenticate and recover their Turnkey accounts using email-based verification. There are two methods of email authentication:"
-sidebarTitle: "Email"
---
**One-Time Password**
@@ -26,7 +25,10 @@ Email Authentication is built with expiring API keys as the foundation. The two
The authentication process happens in two steps:
+
+
+
+ 
+
+
+
+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).
+
+
+ 
+ 
@@ -156,6 +159,7 @@ The auth component contains the UI and logic to handle the authentication flow.
};
```
+
@@ -58,6 +59,7 @@ The API keypair is used to authenticate requests to Turnkey. We'll create one no
+
@@ -40,384 +53,180 @@ mode: "wide"
/>
-## About
+# Turnkey's Products
-[Turnkey](https://turnkey.com) is highly flexible key management infrastructure, purpose-built for security and scale. Our API and open-source SDKs make it easy for you to take your product from 0 to 1, and enable developers to create millions of embedded wallets and automate complex onchain transactions.
+Turnkey covers two main use cases: Embedded Wallets and Transaction Automation.
-Whether you're building a DeFi platform, a payments app, an AI agent, or anything requiring a private key, Turnkey offers the building blocks to bring your ideas to life.
+## Embedded Wallets
-Our solution covers two main use cases:
+Turnkey's Embedded Wallets offer the most secure way to integrate wallets into your app. With Turnkey, you can create millions of embedded wallets on behalf of your users for a flawless onboarding and in-app experience.
-
-{/* Ensure the text content of this heading below ↓ "Here's how..." matches the href in styles.css to keep it hidden in the table of contents */}
-
-### Here's how that works:
+There is no set relationship between organizations, sub-organizations, activities, wallets, and resources.
+This makes Turnkey highly flexible and configurable to any use case.
-- **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 and _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.
+For a more in-depth overview, learn more [here](/concepts/overview).
-
-
-
-
+ 
+ Unsupported method
+
+## Email Customization
+
+We offer customization for the following:
+
+- `appName`: the name of the application. This will be used in the email's subject, e.g. `Sign in to ${appName}`
+- `logoUrl`: a link to a PNG with a max width of 340px and max height of 124px
+- `magicLinkTemplate`: a template for the URL to be used in the magic link button, e.g. `https://dapp.xyz/%s`. The auth bundle will be interpolated into the `%s`
+
+```js
+// Sign and submits the EMAIL_AUTH activity
+const response = await client.emailAuth({
+ type: "ACTIVITY_TYPE_EMAIL_AUTH",
+ timestampMs: String(Date.now()),
+ organizationId: 
+- **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 and 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:
@@ -70,52 +88,13 @@ Resources used to generate crypto addresses and sign transactions or messages. W
Learn more about leveraging Wallets across different crypto ecosystems on our [Ecosystem Support](/networks/framework) page.
-## Typical implementations
-
-### Transaction Automation
-
-Transaction automation entails a business signing transactions on its own behalf. For example, automating payments flows, managing smart contract deployment or programmatically trading in DeFi.
-
-
- 
-
-
-In this setup, the business is in full control of its wallets at all times. This use case typically does not require the use of sub-organizations and everything can be managed from the parent organization. We suggest the following setup:
-
-- **Root Users:** After initial setup of your parent organization, set a reasonable root quorum (e.g., 2 of 3), attach backup credentials to each user for safekeeping, and only use the root users in a “break glass” scenario.
-- **Service Users:** Create different users for separate services and/or approval workflows. For example, you might have user A that can automatically sign any transaction with Wallet X, but require both user A and user B to approve transactions with Wallet B.
-- **Service Policies:** Set appropriately restrictive policies based on your security needs.
-- **Wallets:** Create separate wallets where differentiated policies are needed, otherwise just leverage multiple wallet accounts within a single wallet.
-
-### Embedded Wallets
-
-Embedded wallets entail a business creating non-custodial wallets controlled by its end users. For example, allowing an end user to create and use a wallet via Web2 authentication methods like email or OAuth.
-
-
- 
-
-
-This is a non-custodial setup where the end user is in control of its wallet at all times. This use case requires the use of sub-organizations which map to an individual end user, and does not require any wallets in the parent organization. The parent organization will be used by your backend service for onboarding new users and initiating certain authentication methods (e.g., email, SMS), while the sub-organizations will be used by the end users for day-to-day signing. We suggest the following setup:
-
-- **Root Users:** After initial setup of your parent organization, set a reasonable root quorum (e.g., 2 of 3), attach backup credentials to each user for safekeeping, and only use the root users in a “break glass” scenario.
-- **Normal Users:** Create a single service user used for user onboarding and authentication.
-- **Policies:** Set a policy granting the user permission to `CREATE_SUB_ORGANIZATION`, `EMAIL_AUTH`, `OAUTH`, `OTP_AUTH`. For examples of how to create such policies [look here](/concepts/policies/examples).
-- **Sub-organizations:** Create individual sub-organizations for each user that contain a single root user with any relevant credentials, and a single wallet with any relevant wallet accounts.
-
-For more details on each individual concepts, refer to the pages below:
-
-
-
-Almost all actions on Turnkey are implicitly denied by default. There are a few exceptions, however:
-
-* Root users bypass any policies.
-* All users have implicit GET (read) permissions in their own Organization and any associated Sub-Organizations.
-* All users have implicit permission to change their own credentials.
-* All users have implicit permission to approve an activity if they were included in consensus (i.e., a user specified as part of the consensus required to approve a SIGN\_TRANSACTION activity does not need separate, explicit permission to sign transactions).
+