update sdk example links for categorization change

api-reference/overview/errors.mdx

@@ -642,7 +642,7 @@ Common causes:
 Troubleshooting tips:
 
 - The attestation generated by the authenticator includes a new key pair, the challenge, and device metadata that is signed, read more about attestations [here](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/Attestation_and_Assertion).
-- An example of getting the correct parameters needed to use the Create Authenticators endpoint can be found within our [react-components](https://github.com/tkhq/sdk/blob/main/examples/react-components/src/app/dashboard/page.tsx#L246-L276) SDK example
+- An example of getting the correct parameters needed to use the Create Authenticators endpoint can be found within our [react-components](https://github.com/tkhq/sdk/blob/main/examples/demos/react-components/src/app/dashboard/page.tsx#L246-L276) SDK example
 
 ### invalid authenticator attestation
 
@@ -653,7 +653,7 @@ Common causes:
 Troubleshooting tips:
 
 - The attestation generated by the authenticator includes a new key pair, the challenge, and device metadata that is signed, read more about attestations [here](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/Attestation_and_Assertion).
-- An example of getting the correct parameters needed to use the Create Authenticators endpoint can be found within our [react-components](https://github.com/tkhq/sdk/blob/main/examples/react-components/src/app/dashboard/page.tsx#L246-L276) SDK example
+- An example of getting the correct parameters needed to use the Create Authenticators endpoint can be found within our [react-components](https://github.com/tkhq/sdk/blob/main/examples/demos/react-components/src/app/dashboard/page.tsx#L246-L276) SDK example
 
 ### missing parameter: user authenticator attestation auth data
 
@@ -663,7 +663,7 @@ Common causes:
 
 Troubleshooting tips:
 
-- An example of getting the correct parameters needed to use the Create Authenticators endpoint can be found within our [react-components](https://github.com/tkhq/sdk/blob/main/examples/react-components/src/app/dashboard/page.tsx#L246-L276) SDK example
+- An example of getting the correct parameters needed to use the Create Authenticators endpoint can be found within our [react-components](https://github.com/tkhq/sdk/blob/main/examples/demos/react-components/src/app/dashboard/page.tsx#L246-L276) SDK example
 
 ### user has exceeded maximum authenticators
 

changelogs/ethers/readme.mdx

@@ -1140,7 +1140,7 @@ const turnkeySigner = new TurnkeySigner({
 
 - Update documentation as follows:
 - ebf87a9: This breaking change adds support for stampers (@turnkey/api-key-stamper / @turnkey/webauthn-stamper) to integrate with API keys or passkeys, bringing it to parity with our [Viem](https://github.com/tkhq/sdk/tree/main/packages/viem) package. See the following examples for sample usage:
-  - [with-ethers](https://github.com/tkhq/sdk/tree/main/examples/with-ethers): updated to use `@turnkey/api-key-stamper`
+  - [with-ethers](https://github.com/tkhq/sdk/tree/main/examples/chain-integrations/with-ethers): updated to use `@turnkey/api-key-stamper`
   - [with-ethers-and-passkeys](https://github.com/tkhq/sdk/tree/main/examples/with-ethers-and-passkeys): demonstrates usage of `@turnkey/webauthn-stamper`
 
 ## 0.17.0

changelogs/http/readme.mdx

@@ -290,7 +290,7 @@ mode: wide
 ### Minor Changes
 
 - 3e4a482: Release per mono v2025.4.4
-  - Adds parsing and policy engine support for Ethereum Type 3 (EIP-4844) and Type 4 (EIP-7702) transactions. There is no change to any signing interface or API; you simply can now use Turnkey's signing endpoints to sign those transaction types. See [with-viem](https://github.com/tkhq/sdk/blob/main/examples/with-viem/) for examples.
+  - Adds parsing and policy engine support for Ethereum Type 3 (EIP-4844) and Type 4 (EIP-7702) transactions. There is no change to any signing interface or API; you simply can now use Turnkey's signing endpoints to sign those transaction types. See [with-viem](https://github.com/tkhq/sdk/tree/main/examples/chain-integrations/with-viem/) for examples.
   - New wallet account creations will now automatically derive the underlying derived account's public key. For example: previously, if derived an Ethereum wallet account, you would get the resulting Ethereum address (`0x...`). If you also wanted the public key associated with that underlying key, you would've had to derive an additional wallet account with `ADDRESS_FORMAT_COMPRESSED`. Now, this will automatically be derived for you. It is now a property that has been added to the wallet account primitive (i.e. accessible via `walletAccount.publicKey`).
 
 ## 3.0.0
@@ -756,7 +756,7 @@ Signing is now performed through Turnkey stampers. New dependencies:
 
 ### Minor Changes
 
-- Add support for federated requests (an example is included under `sdk/examples/with-federated-passkeys`)
+- Add support for federated requests (an example is included under `sdk/examples/authentication/with-federated-passkeys`)
 - Routine re-sync protos from mono
 
 ## 0.17.1

changelogs/viem/readme.mdx

@@ -555,7 +555,7 @@ mode: wide
 
 - 2f75cf1: Add support for signing Type 3 (EIP-4844) transactions
   - Note the inline comments on the `signTransaction` [implementation](https://github.com/tkhq/sdk/blob/5e5666aba978f756e2021c261830effc5559811f/packages/viem/src/index.ts#L392): when signing Type 3 transactions, our Viem implementation will extract the transaction payload (not including blobs, commitments, or proofs), sign it, extract the signature, and then reassemble the entire transaction payload.
-  - See [with-viem](https://github.com/tkhq/sdk/tree/main/examples/with-viem/) for examples.
+  - See [with-viem](https://github.com/tkhq/sdk/tree/main/examples/chain-integrations/with-viem/) for examples.
 
 ### Patch Changes
 

features/authentication/auth-proxy.mdx

@@ -45,7 +45,7 @@ Used to authenticate users with a one-time code sent to their email or phone num
 
 1. **[Init OTP](/api-reference/auth-proxy/otp-init)** `POST /v1/otp_init_v2` — Send an OTP code to the user's email or phone. Returns an `otpId` and an `otpEncryptionTargetBundle`.
 
-   > `otpEncryptionTargetBundle` is a TEE-signed bundle containing a target P-256 encryption key. The client uses it to encrypt the OTP code before submission, so the code is only decryptable inside the enclave. If you're using `react-wallet-kit` this is handled automatically — see the [otp-auth/without-backend](https://github.com/tkhq/sdk/tree/main/examples/otp-auth/without-backend) example.
+   > `otpEncryptionTargetBundle` is a TEE-signed bundle containing a target P-256 encryption key. The client uses it to encrypt the OTP code before submission, so the code is only decryptable inside the enclave. If you're using `react-wallet-kit` this is handled automatically — see the [otp-auth/without-backend](https://github.com/tkhq/sdk/tree/main/examples/authentication/otp-auth/without-backend) example.
 
 2. **[Verify OTP](/api-reference/auth-proxy/otp-verify)** `POST /v1/otp_verify_v2` — Submit the OTP code along with the `otpId`. Returns a `verificationToken` — a short-lived, enclave-signed token proving the user owns the contact.
 

features/authentication/bring-your-own-auth.mdx

@@ -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](/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.
+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/authentication/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
 

features/authentication/email.mdx

@@ -49,7 +49,7 @@ The authentication process happens in two steps:
 The API key credential is encrypted and delivered directly through email to the user. Once the credential is live on the client side (within the context of an iframe), it is readily available to stamp (authenticate) requests. See the [enclave to end-user secure channel](/security/enclave-secure-channels) for more info on how we achieve secure delivery.
 
 This flow remains available for existing legacy integrations but is not recommended for new implementations.
-As an alternative, we recommend using the email OTP flow, which is fully supported by the current SDKs. An example that sends a magic link using [magicLinkTemplate](https://docs.turnkey.com/authentication/email#email-auth-and-recovery:~:text=height%20of%20124px-,magicLinkTemplate,-%3A%20a%20template%20for) can be found [here](https://github.com/tkhq/sdk/tree/main/examples/magic-link-auth).
+As an alternative, we recommend using the email OTP flow, which is fully supported by the current SDKs. An example that sends a magic link using [magicLinkTemplate](https://docs.turnkey.com/authentication/email#email-auth-and-recovery:~:text=height%20of%20124px-,magicLinkTemplate,-%3A%20a%20template%20for) can be found [here](https://github.com/tkhq/sdk/tree/main/examples/authentication/magic-link-auth).
 
 ### Email recovery
 
@@ -335,8 +335,8 @@ Specifically:
 
 ### Example implementations
 
-- [OTP Auth Example](https://github.com/tkhq/sdk/tree/main/examples/otp-auth)
-- [Email Auth Example](https://github.com/tkhq/sdk/tree/main/examples/email-auth)
+- [OTP Auth Example](https://github.com/tkhq/sdk/tree/main/examples/authentication/otp-auth)
+- [Email Auth Example](https://github.com/tkhq/sdk/tree/main/examples/authentication/email-auth)
 - [Demo Embedded Wallet](https://wallet.tx.xyz) ([code](https://github.com/tkhq/demo-embedded-wallet))
 
 ## Implementation in organizations

features/authentication/passkeys/integration.mdx

@@ -25,7 +25,7 @@ This flow happens once for **registration** and for each subsequent **authentica
 
 Our SDK has integrated passkey functionality, and we've built examples to help you get started.
 
-* [`@turnkey/http`](https://www.npmjs.com/package/@turnkey/http) has a helper to trigger passkey registration (`getWebAuthnAttestation`). You can see it in action in our [`with-federated-passkeys`](https://github.com/tkhq/sdk/tree/main/examples/with-federated-passkeys) example: [direct code link](https://github.com/tkhq/sdk/blob/a2bfbf3cbd6040902bbe4c247900ac560be42925/examples/with-federated-passkeys/src/pages/index.tsx#L88)
+* [`@turnkey/http`](https://www.npmjs.com/package/@turnkey/http) has a helper to trigger passkey registration (`getWebAuthnAttestation`). You can see it in action in our [`with-federated-passkeys`](https://github.com/tkhq/sdk/tree/main/examples/authentication/with-federated-passkeys) example: [direct code link](https://github.com/tkhq/sdk/blob/a2bfbf3cbd6040902bbe4c247900ac560be42925/examples/authentication/with-federated-passkeys/src/pages/index.tsx#L88)
 
 * [`@turnkey/webauthn-stamper`](https://www.npmjs.com/package/@turnkey/webauthn-stamper) is a passkey-compatible stamper which integrates seamlessly with `TurnkeyClient`:
 

features/authentication/proxying-signed-requests.mdx

@@ -10,5 +10,5 @@ How should you decide what to do? Here are some considerations:
 * POSTing signed requests directly from your app frontend to Turnkey saves you the burden of running a proxy server, and takes you out of the loop so that your end-users interact directly with Turnkey. This is a "hands-off" approach that can work well if you want to give your end-users maximum flexibility and ownership over their sub-organization.
 
 <Note>
-  For a working end-to-end implementation, see the [with-proxy-signed-requests example](https://github.com/tkhq/sdk/tree/main/examples/with-proxy-signed-requests).
+  For a working end-to-end implementation, see the [with-proxy-signed-requests example](https://github.com/tkhq/sdk/tree/main/examples/advanced/with-proxy-signed-requests).
 </Note>

features/authentication/sessions.mdx

@@ -64,8 +64,8 @@ Turnkey’s SDK provides helpers to:
 
 This is currently the **most persistent** session model for modern browsers that support WebCrypto. It is especially valuable in Progressive Web App (PWA) contexts or when iframe and Local Storage approaches are insufficient.
 
-To see the IndexedDB-backed session mechanism in action, check out our Turnkey react-wallet-kit [playground](https://github.com/tkhq/sdk/tree/main/examples/with-sdk-js) or dedicated authentication examples like [oauth](https://github.com/tkhq/sdk/tree/main/examples/oauth), [email OTP](https://github.com/tkhq/sdk/tree/main/examples/otp-auth), and [external wallet authentication](https://github.com/tkhq/sdk/tree/main/examples/wallet-auth).
-Our [Web demo application](https://github.com/tkhq/sdk/tree/main/examples/react-wallet-kit) hosted at [wallets.turnkey.com](https://wallets.turnkey.com) showcases complete end-to-end authentication flows and client-side session persistence backed by IndexedDB.
+To see the IndexedDB-backed session mechanism in action, check out our Turnkey react-wallet-kit [playground](https://github.com/tkhq/sdk/tree/main/examples/demos/with-sdk-js) or dedicated authentication examples like [oauth](https://github.com/tkhq/sdk/tree/main/examples/authentication/oauth), [email OTP](https://github.com/tkhq/sdk/tree/main/examples/authentication/otp-auth), and [external wallet authentication](https://github.com/tkhq/sdk/tree/main/examples/authentication/wallet-auth).
+Our [Web demo application](https://github.com/tkhq/sdk/tree/main/examples/demos/react-wallet-kit) hosted at [wallets.turnkey.com](https://wallets.turnkey.com) showcases complete end-to-end authentication flows and client-side session persistence backed by IndexedDB.
 
 
 #### SecureStorage (mobile only)

features/authentication/social-logins.mdx

@@ -3,7 +3,7 @@ title: "Social logins"
 description: "Social logins provide a familiar and convenient way for users to access applications using their existing accounts from popular platforms like Google, Apple, Facebook, X/Twitter, etc. Under the hood, this functionality is powered by OAuth - a robust auth protocol which enables secure user verification through OpenID Connect ([OIDC](https://openid.net/specs/openid-connect-core-1_0.html)) tokens. This feature is available exclusively for sub-organization users."
 ---
 
-Similar to [email auth](/features/authentication/email), social login authentication is ideal for users who prefer not to manage API keys or [passkeys](/features/authentication/passkeys/introduction) directly. This makes it particularly well-suited for onboarding users who are comfortable with traditional web2-style accounts but may be unfamiliar with cryptographic keys and credentials. An example implementing social login authentication for an organization can be found in our SDK repo [here](https://github.com/tkhq/sdk/tree/main/examples/oauth).
+Similar to [email auth](/features/authentication/email), social login authentication is ideal for users who prefer not to manage API keys or [passkeys](/features/authentication/passkeys/introduction) directly. This makes it particularly well-suited for onboarding users who are comfortable with traditional web2-style accounts but may be unfamiliar with cryptographic keys and credentials. An example implementing social login authentication for an organization can be found in our SDK repo [here](https://github.com/tkhq/sdk/tree/main/examples/authentication/oauth).
 
 ## Types of social login providers
 
@@ -376,12 +376,12 @@ Once uploaded, you can then use the **Credential Id**  from the table shown to m
 
 ![Facebook OAuth flow](/images/authentication/img/social-logins-table.png)
 
-You can also see the example [here](https://github.com/tkhq/sdk/blob/main/examples/with-x/credential-upload.tsx) demonstrating how to encrypt and upload your client secrets using our SDK instead.
+You can also see the example [here](https://github.com/tkhq/sdk/blob/main/examples/authentication/with-x/credential-upload.tsx) demonstrating how to encrypt and upload your client secrets using our SDK instead.
 
 ### Returning the encrypted bearer token
 
 When using OAuth 2.0-Only Social Providers, it is also possible to have the bearer token returned by the `OAuth2Authenticate` endpoint, which can be useful if you would like your app to have additional integrations involving this Social Provider.
 
 In order to guarantee the secure transfer of the bearer token, it must be encrypted to a P256 Encryption Key inside our secure enclave, returned to the caller, and then finally decrypted. Therefore, the return of the encrypted bearer token is dependent on the caller providing an optional `bearerTokenTargetPublicKey` parameter in the request to `OAuth2Authenticate`.
 
-An example demonstrating this flow can be seen [here](https://github.com/tkhq/sdk/blob/main/examples/with-x/src/app/auth/turnkey/x/route.ts).
+An example demonstrating this flow can be seen [here](https://github.com/tkhq/sdk/blob/main/examples/authentication/with-x/src/app/auth/turnkey/x/route.ts).

features/networks/aptos.mdx

@@ -11,7 +11,7 @@ Turnkey supports Aptos address derivation with `ADDRESS_TYPE_APTOS`. Aptos addre
 
 Turnkey supports Aptos transaction signing through our core signing capabilities. We have an example repository that demonstrates how to construct and sign Aptos transactions:
 
-- [`examples/with-aptos`](https://github.com/tkhq/sdk/tree/main/examples/with-aptos): demonstrates transaction construction and broadcast on Aptos.
+- [`examples/chain-integrations/with-aptos`](https://github.com/tkhq/sdk/tree/main/examples/chain-integrations/with-aptos): demonstrates transaction construction and broadcast on Aptos.
 
 ## Example
 

features/networks/bitcoin.mdx

@@ -103,6 +103,6 @@ Context on signing, and sighash conventions for Taproot can be found on Learn Me
 
 ## SDK example
 
-If you want to get started with Bitcoin we encourage you to look at the following SDK example: [`examples/with-bitcoin`](https://github.com/tkhq/sdk/tree/main/examples/with-bitcoin). It showcases transaction construction and signing with [`bitcoinjs-lib`](https://github.com/bitcoinjs/bitcoinjs-lib), a widely used JS library.
+If you want to get started with Bitcoin we encourage you to look at the following SDK example: [`examples/chain-integrations/with-bitcoin`](https://github.com/tkhq/sdk/tree/main/examples/chain-integrations/with-bitcoin). It showcases transaction construction and signing with [`bitcoinjs-lib`](https://github.com/bitcoinjs/bitcoinjs-lib), a widely used JS library.
 
-This demo contains a client-side [signer](https://github.com/tkhq/sdk/blob/main/examples/with-bitcoin/src/signer.ts) which seamlessly integrates Turnkey signing with this library for both taproot and non-taproot output signatures. Let us know if you're interested in using it. We have not yet published it as a standalone NPM package, but could do it if we hear enough interest!
+This demo contains a client-side [signer](https://github.com/tkhq/sdk/blob/main/examples/chain-integrations/with-bitcoin/src/signer.ts) which seamlessly integrates Turnkey signing with this library for both taproot and non-taproot output signatures. Let us know if you're interested in using it. We have not yet published it as a standalone NPM package, but could do it if we hear enough interest!

features/networks/cosmos.mdx

@@ -15,7 +15,7 @@ To construct and sign Cosmos transactions with Turnkey, we offer:
 
 See it in action in our example:
 
-- [`examples/with-cosmjs`](https://github.com/tkhq/sdk/tree/main/examples/with-cosmjs): demonstrates transaction construction and broadcast on Cosmos.
+- [`examples/chain-integrations/with-cosmjs`](https://github.com/tkhq/sdk/tree/main/examples/chain-integrations/with-cosmjs): demonstrates transaction construction and broadcast on Cosmos.
 
 ## Example