> ## Documentation Index > Fetch the complete documentation index at: https://docs.apostra.com/llms.txt > Use this file to discover all available pages before exploring further. # Create account > Create a new account under your organization `POST /api/v2/accounts/create-child` ## Availability Creates a new account under your organization. Requires the `ADMIN` role on the organization and an accepted package with an unused account slot. If your account is standalone, the package must include at least two account slots. You must also be its direct administrator and explicitly confirm creation of a new organization. Present the consequences below and send the confirmation as exactly `true`. A direct Advertiser package starts with its included account. **Add account** appears only after an accepted package adds another account slot; advertiser objects and connected advertising-platform accounts do not consume these organization account slots. The organization created by this conversion is a billing and access container, not a Buyer or Seller account. Your current contract and billing authority move to it, and you become its first administrator. The existing account keeps its role, resources, and direct members; organization administrators can manage both accounts, while direct account members gain no organization authority. Any account-specific standing remains an override; otherwise the account inherits organization standing. Detachment is not self-service because it requires a dedicated contract, billing, standing, and administrator migration. Only a newly created `SELLER` account receives a new storefront. A new `BUYER` account can enter Buyer Setup immediately. Its demo, real-work, direct-spend, and Apostra-spend capabilities are derived from Organization proof, Terms, plan/entitlements, standing, and transaction route; no separate admission flips the Account live. The confirmation controls whether a fresh standalone conversion may begin. If a matching `idempotencyKey` receipt has already committed the organization and account hierarchy, retrying with that same key resumes required administrator access, contract transfer, compatibility projections, and account-view repairs even when `confirmOrganizationConversion` is omitted or `false`. The retry cannot cancel or reverse authority that has already moved. Reusing the key with incompatible input still returns `409 Conflict`. ## Request Standalone conversion example: ```bash curl theme={null} curl -X POST https://api.apostra.com/api/v2/accounts/create-child \ -H "Authorization: Bearer $SCOPE3_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "Acme Retail", "customerRole": "BUYER", "idempotencyKey": "child-account:acme-retail-2026", "parentName": "Acme HQ", "customerDomain": "acmeretail.com", "confirmOrganizationConversion": true }' ``` For seller accounts, include the storefront settlement currency up front so the auto-created storefront does not require a separate currency setup step: ```json Seller account theme={null} { "name": "Acme Media", "customerRole": "SELLER", "idempotencyKey": "child-account:acme-media-2026", "customerDomain": "acmemedia.com", "defaultCurrency": "USD", "paymentCurrencies": ["USD"] } ``` Apostra platform administrators can instead create a leased synthetic seller: ```json Demo seller account theme={null} { "name": "Acme Media Demo", "customerRole": "SELLER", "accountMode": "DEMO", "demoRecipeIds": ["sample-publisher-display"], "demoFeatureProfileName": "seller-sources/merchandising-distribution" } ``` ## Parameters | Field | Type | Required | Notes | | ------------------------------- | --------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `name` | string | Yes | Name for the new account (1–255 chars) | | `customerRole` | enum | Yes | Legacy request name for the account type: `BUYER` or `SELLER`. Partner is an organization-level workspace and cannot be created here. | | `idempotencyKey` | string | No | Stable key for safely retrying the same creation request (8–128 characters; letters, numbers, `.`, `_`, `:`, and `-`). Reusing a matching key resumes repairs or returns the same result; it cannot cancel committed organization attachment. | | `parentName` | string | No | Name for the organization created during standalone conversion. Defaults to the standalone account's current name. | | `confirmOrganizationConversion` | boolean | Standalone only | Send exactly `true` after the standalone administrator has reviewed the contract, billing, standing, membership, and detachment consequences. Omit for accounts already managed by an organization. Omission or `false` rejects a fresh conversion, but does not stop a same-key retry after its matching receipt committed the hierarchy. | | `customerDomain` | string | No | Registered domain for the account (max 255, valid hostname). For `BUYER`, use the domain of the operator that runs the account. For `SELLER`, use the domain of the company operating the storefront; it initially seeds the storefront's operator domain and remains separate from its public listing domain. | | `defaultCurrency` | string | Seller | Primary storefront settlement currency. Required when `paymentCurrencies` is non-empty. | | `paymentCurrencies` | string\[] | No | Storefront settlement currencies. For `SELLER`, include `defaultCurrency`; omit or pass `[]` to use only the primary currency. | | `accountMode` | enum | No | Internal provisioning mode: `STANDARD` (default) or `DEMO`. `DEMO` is restricted to Apostra platform administrators and requires a `SELLER` account. | | `demoRecipeIds` | string\[] | Demo | One to three versioned synthetic source recipes. Demo accounts must include `sample-publisher-display`. | | `demoFeatureProfileName` | enum | No | Seller capabilities for this Demo lease: `seller-sources/listing-only`, `seller-sources/listing-distribution`, `seller-sources/merchandising`, or `seller-sources/merchandising-distribution`. Defaults to Merchandising + Distribution and does not change the organization's commercial profile. | ## Response Returns the full user context scoped to the new account. `buyerAccessPosture` remains in this response only as a deprecated compatibility projection and must not be used for authorization. Read Buyer Setup capabilities. ```json theme={null} { "user": { "id": 4412, "email": "buyer@acmeretail.com", "firstName": "Sam", "lastName": "Rivera", "role": "ADMIN" }, "customer": { "id": 200, "company": "Acme Retail", "name": "Acme Retail", "active": true, "customerRole": "BUYER", "customerType": "CHILD", "nodeKind": "ACCOUNT", "accountType": "BUYER", "enabled": true, "buyerAccessPosture": "SANDBOX_ONLY", "accountProducts": { "core": { "nodeKind": "ACCOUNT", "accountType": "BUYER", "customerId": 200, "enabled": true, "buyerAccessPosture": "SANDBOX_ONLY", "customerRole": "BUYER" }, "partner": null } }, "customers": [ { "id": 100, "company": "Acme", "name": "Acme HQ", "membershipRole": "ADMIN", "role": "ADMIN", "nodeKind": "CONTAINER", "accountType": null, "enabled": true }, { "id": 200, "company": "Acme Retail", "name": "Acme Retail", "membershipRole": "ADMIN", "role": "ADMIN", "customerRole": "BUYER", "nodeKind": "ACCOUNT", "accountType": "BUYER", "enabled": true } ], "showTosBox": false, "hasContract": true, "latestTosVersion": "2026-01", "convertedFromStandalone": true } ``` | Field | Type | Notes | | ----------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `user` | object | User profile data | | `customer` | object | Context for the newly created account. Canonical fields include `nodeKind`, `accountType`, and `enabled`; `customerRole` and Buyer `buyerAccessPosture` remain as deprecated compatibility projections. | | `customers` | array | All organizations and accounts the user can access, including canonical `nodeKind`, `accountType`, `enabled`, and `membershipRole` fields. | | `showTosBox` | boolean | Whether to show the ToS acceptance dialog | | `organizationContractMissing` | boolean (optional) | Included as `true` when the inherited organization has no active contract; otherwise omitted. Block usage until an org admin accepts ToS. | | `hasContract` | boolean | Whether the account has an active contract | | `latestTosVersion` | string | Latest Terms of Service version identifier | | `convertedFromStandalone` | boolean | `true` if the request triggered a standalone-to-organization conversion | ## Errors * `400 VALIDATION_ERROR` — missing required field or `customerDomain` fails the hostname pattern. * `401 UNAUTHORIZED` — missing or invalid bearer token. * `403 ACCESS_DENIED` — caller is not an administrator, or the organization has no active package granting account capacity. * `409 CONFLICT` — no account slot remains, a fresh standalone conversion omitted `confirmOrganizationConversion: true` or sent `false`, or the request reused an idempotency key with incompatible input. A matching same-key retry after the hierarchy committed resumes instead of returning this confirmation error. See [Errors](/v2/reference/errors) for the full error contract. ## Related All account operations Remove an account from your organization Set the registered domain