> ## Documentation Index > Fetch the complete documentation index at: https://docs.mystacks.ai/llms.txt > Use this file to discover all available pages before exploring further. # Manager API overview > Authentication, responses, and integration rules for wealth managers. The Manager API lets wealth managers create and publish stacks. A stack defines a name, target asset allocation, and rebalance schedule. You can list your stacks, read their current configuration, and update them. Each subscriber holds assets in their own smart account. ## Base URL Use this base URL for staging: ```text theme={null} https://api-staging.mystacks.ai ``` Set it once for the examples: ```bash theme={null} export MYSTACKS_API_BASE_URL="https://api-staging.mystacks.ai" ``` The examples append the full `/manager` endpoint path. MyStacks provides the appropriate API key for your environment. Staging uses Robinhood Chain mainnet assets. It is not a testnet asset environment. ## API keys **MyStacks generates API keys and gives them to wealth managers.** Contact your MyStacks team to receive a key or arrange its replacement or revocation. There is no self-service key creation endpoint. Send your key in the `Authorization` header on every manager request: ```http theme={null} Authorization: Bearer ``` Keep the key on your server or in your API client's secret storage. Manager routes do not grant browser CORS access. They require no user login session or browser cookies. The key identifies your manager account. You cannot choose another manager through a request body or query parameter. You can only read and change stacks owned by that account. A missing stack and a stack owned by another manager both return `404`. ## Check your connection Open [List stacks](/api-reference/stacks/list) and click **Try it**. Enter the API key supplied by MyStacks in the Bearer authentication field. The playground adds the `Authorization: Bearer` prefix for you. Click **Send** to call staging and see the response. The docs playground routes requests through Mintlify's proxy. Your supplied key is included in that request. Create and update requests make real changes to staging stacks. You can also use a terminal: Set `MYSTACKS_MANAGER_API_KEY` to the key supplied by MyStacks. Then list your stacks: ```bash theme={null} curl --include "${MYSTACKS_API_BASE_URL}/manager/stacks?limit=25" \ --header "Authorization: Bearer ${MYSTACKS_MANAGER_API_KEY}" ``` A manager with no stacks receives `200 OK` with: ```json theme={null} { "items": [], "next_cursor": null } ``` Your first authenticated request sets up your manager record automatically. You do not need to register it through a separate endpoint. ## Endpoints | Method | Path | Purpose | | ------- | ------------------------------------------------------ | --------------------------------------- | | `POST` | [`/manager/stacks`](/api-reference/stacks/create) | Create and immediately publish a stack. | | `GET` | [`/manager/stacks`](/api-reference/stacks/list) | List your stacks. | | `GET` | [`/manager/stacks/{id}`](/api-reference/stacks/get) | Read one stack's current configuration. | | `PATCH` | [`/manager/stacks/{id}`](/api-reference/stacks/update) | Save changes as a new revision. | These are the complete manager route set. The API has no manager endpoint for deletion, revision history, subscriber holdings, withdrawals, or manual rebalancing. Public stack discovery uses separate `/app` routes. ## Response format Single-stack success responses return the [stack object](/api-reference/stack-configuration#stack-response) directly. List responses return `items` and `next_cursor` at the top level. There is no `success` or `data` wrapper. Errors use this shape: ```json theme={null} { "code": "unauthorized", "message": "invalid manager credential", "request_id": "d28e1ad4-2ca8-4f35-b590-8bf3b53abc81" } ``` See [errors and retries](/api-reference/errors) for all status codes. ## Headers | Header | Direction | Rule | | ----------------- | -------------------- | ---------------------------------------------------------------------------------------------- | | `Authorization` | Request | Required on every manager request. Use `Bearer `. | | `Content-Type` | Request | Send `application/json` with create and update bodies. | | `Idempotency-Key` | Request | Required for stack creation. See [creation retries](/api-reference/stacks/create#idempotency). | | `X-Request-Id` | Request and response | Optional on requests. Every response includes it. | | `ETag` | Response | Quoted current revision UUID on successful create, single-stack read, and update responses. | The server reuses a nonempty incoming `X-Request-Id`. Otherwise it generates a UUID. An error's `request_id` matches the response header. Include this value when reporting a problem to MyStacks. `ETag` identifies the returned revision. It does not provide conditional update protection. See [concurrent updates](/api-reference/stacks/update#revisions-and-concurrent-updates). ## Input conventions * Stack and revision IDs are UUIDs. * Token identities use EVM contract addresses on Robinhood Chain `4663`. * Weights are integer basis points. `10000` means 100%. * Schedule presets use fixed UTC boundaries. * JSON bodies are limited to 262,144 bytes (256 KiB). * Create and update reject unsupported fields, including nested fields. See [stack configuration](/api-reference/stack-configuration) for exact validation rules. Send a complete allocation and schedule with a creation retry key. ## OpenAPI specification [Download the Manager API specification](/api-reference/openapi.json) to import it into an API client or generate a typed client. The same specification powers the endpoint request forms and response schemas in these docs.