diff --git a/docs/getting-started/Sub-Organizations.md b/docs/getting-started/Sub-Organizations.md
index e959469..4ca33c0 100644
--- a/docs/getting-started/Sub-Organizations.md
+++ b/docs/getting-started/Sub-Organizations.md
@@ -63,7 +63,7 @@ The application then uses an API-only user to create a new sub-organization on b
     }],
     "rootQuorumThreshold": 1,
     "wallet": {
-      "walletName": "Default ETH Wallet",
+      "walletName": "Default Wallet",
       "accounts": [
         {
           "curve": "CURVE_SECP256K1",
@@ -77,6 +77,18 @@ The application then uses an API-only user to create a new sub-organization on b
 }
 ```
 
+The response will resemble the following:
+
+```json
+{
+  "subOrganizationId": "<your-new-sub-org>", // the organization_id that the end-user must use when signing requests
+  "wallet": {
+    "walletId": "<your-new-wallet>", // the wallet ID used to generate more accounts
+    "addresses": "<your-new-addresses>" // the addresses you can now sign with
+  }
+}
+```
+
 Note: by default, root users created with sub-organizations will have both API and authenticator (e.g. passkey) access permitted.
 
 With this setup each end-user now has sole control over their sub-organization and any resources created within it. Your application cannot take any actions on resources within the sub-organization without explicitly cryptographic authorization from the end-user in the form of a passkey signature.
@@ -114,7 +126,7 @@ const signedRequest = await httpClient.stampCreateWallet({
   organizationId: "<user sub-organization>",
   timestampMs: String(Date.now()),
   parameters: {
-    walletName: "New ETH Wallet",
+    walletName: "New Wallet",
     accounts: [
       {
         curve: "CURVE_SECP256K1",
@@ -131,6 +143,29 @@ The `signedRequest` contains all the components needed to forward it to turnkey:
 
 You can choose to send this request straight from your frontend, or proxy it through your backend server. If you want to send from the frontend, you can use `httpClient.createWallet` instead.
 
+#### Step 2a: Creating additional wallet accounts
+
+Next, we can derive additional accounts (addresses) given a single HD wallet. The shape of the request is as follows:
+
+```json
+{
+  "type": "ACTIVITY_TYPE_CREATE_WALLET_ACCOUNTS",
+  "timestampMs": "<time-in-ms>",
+  "organizationId": "<your-organization-id>",
+  "parameters": {
+    "walletId": "<your-wallet-id>",
+    "accounts": [
+      {
+        "curve": "CURVE_SECP256K1",
+        "pathFormat": "PATH_FORMAT_BIP32",
+        "path": "m/44'/60'/0'/0/0",
+        "addressFormat": "ADDRESS_FORMAT_ETHEREUM",
+      },
+    ]
+  }
+}
+```
+
 #### Step 3: Transaction signing
 
 Similar to creating a wallet, the end-user must provide a signature over each "Sign Transaction" activity with their passkey. A user action, for example clicking "Withdraw Rewards", might trigger the flow. The details of this transaction are presented to the user for confirmation, followed by a request for their passkey to sign the Turnkey request. The signed request is then proxied and POSTed to Turnkey.