> ## Documentation Index > Fetch the complete documentation index at: https://docs.easierprop.com/llms.txt > Use this file to discover all available pages before exploring further. # Raise max sub-accounts for a key > Authorize additional Extra Accounts on an existing key by raising its `max_accounts` cap. **Strictly raise-only**: the request is rejected if the new value is less than or equal to the current `max_accounts`. ### Authentication Use either: - the dashboard JWT (`Authorization: Bearer `), or - **any** of your `sk_` API keys (`X-API-Key: sk_…`) Auth is **admin-scoped, not key-scoped**: an `sk_` identifies the admin who owns it, so any of your `sk_` keys can manage any of your other keys. For example, using the `sk_` of "user A" to raise the cap on the key of "user B" works as long as both keys belong to the same admin. An `sk_` from a different admin returns `400 Key not found` (the response purposely doesn't distinguish "exists but not yours" from "doesn't exist"). ### Billing impact Extras are billed based on actual sub-accounts attached, so raising the cap by itself does not generate a charge — you only pay once a sub-account beyond the included threshold is actually created. ### Example ```bash curl -X POST https://api.easierprop.com/admin/keys/{id}/max-accounts \ -H 'X-API-Key: sk_…' \ -H 'Content-Type: application/json' \ -d '{"max_accounts": 6}' ``` ## OpenAPI ````yaml /openapi-spec/easierprop.yaml post /admin/keys/{id}/max-accounts openapi: 3.0.3 info: title: Easier Prop REST API version: 2.1.0 description: > MT5 Trading Infrastructure API. Manage multiple broker accounts, execute trades, stream market data, and administer API keys, usage snapshots, and billing terms. **Client API** endpoints live under `/api` and require an `X-API-Key` header. **Admin API** endpoints live under `/admin` and accept either a JWT `Authorization: Bearer ` (obtained via `/admin/login`) or the same `X-API-Key` header used by client endpoints. Admin user provisioning is read-only via REST: `GET /admin/admins` lists admins, but creation, update, and deletion are performed out-of-band (DB / ops tooling). Bootstrap a brand-new deployment with `POST /admin/seed` while no superadmin exists. servers: - url: https://api.easierprop.com description: Production security: [] tags: - name: Admin description: Authentication, API key management, and admin user CRUD - name: Accounts description: Register and manage MT5 broker accounts - name: Sessions description: Control broker connections - name: Trading description: Place, modify, and close orders - name: Account Info description: Balance, equity, margin, and statistics - name: Market Data description: Symbols, quotes, OHLC history, and trade sessions - name: Expert Advisors description: Upload, run, stop, and monitor MQL5 Expert Advisors on your accounts - name: Enhanced description: >- Portfolio, risk, performance, copy-trade, hedge, breakeven, close-all, lot calculator, and position details - name: Extended description: >- Change password, server timezone, symbol sessions, closed positions, mails, tick value, equity stats, and more paths: /admin/keys/{id}/max-accounts: parameters: - name: id in: path required: true schema: type: string format: uuid description: API key ID post: tags: - Admin summary: Raise max sub-accounts for a key description: | Authorize additional Extra Accounts on an existing key by raising its `max_accounts` cap. **Strictly raise-only**: the request is rejected if the new value is less than or equal to the current `max_accounts`. ### Authentication Use either: - the dashboard JWT (`Authorization: Bearer `), or - **any** of your `sk_` API keys (`X-API-Key: sk_…`) Auth is **admin-scoped, not key-scoped**: an `sk_` identifies the admin who owns it, so any of your `sk_` keys can manage any of your other keys. For example, using the `sk_` of "user A" to raise the cap on the key of "user B" works as long as both keys belong to the same admin. An `sk_` from a different admin returns `400 Key not found` (the response purposely doesn't distinguish "exists but not yours" from "doesn't exist"). ### Billing impact Extras are billed based on actual sub-accounts attached, so raising the cap by itself does not generate a charge — you only pay once a sub-account beyond the included threshold is actually created. ### Example ```bash curl -X POST https://api.easierprop.com/admin/keys/{id}/max-accounts \ -H 'X-API-Key: sk_…' \ -H 'Content-Type: application/json' \ -d '{"max_accounts": 6}' ``` operationId: raiseApiKeyMaxAccounts requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/RaiseMaxAccountsRequest' responses: '200': description: Cap raised content: application/json: schema: type: object properties: ok: type: boolean example: true data: $ref: '#/components/schemas/ApiKey' '400': description: | Invalid request — either the value is out of range (1–1000) or it is not strictly greater than the current `max_accounts`. content: application/json: schema: $ref: '#/components/schemas/Error' '401': $ref: '#/components/responses/Unauthorized' '404': $ref: '#/components/responses/NotFound' security: - BearerAuth: [] - ApiKeyHeader: [] components: schemas: RaiseMaxAccountsRequest: type: object required: - max_accounts properties: max_accounts: type: integer description: | New cap value. Must be strictly greater than the key's current `max_accounts`. The endpoint is raise-only by design — it never accepts equal or lower values. minimum: 1 maximum: 1000 example: 5 ApiKey: type: object properties: key: type: string description: Full API key (only returned on creation) example: sk_live_abc123... id: type: string format: uuid example: 70f60784-20f1-45ba-9a04-8e01c0b810c3 label: type: string nullable: true example: Production key prefix: type: string example: sk_live_abc max_accounts: type: integer example: 4 is_active: type: boolean example: true admin_id: type: string format: uuid nullable: true example: 2c0f8d1c-8211-4b67-8ef6-1d8c0f610c3a created_at: type: string format: date-time Error: type: object properties: ok: type: boolean example: false error: type: object properties: code: type: string example: ACCOUNT_NOT_FOUND message: type: string example: Account not found responses: Unauthorized: description: Invalid or missing API key / JWT content: application/json: schema: $ref: '#/components/schemas/Error' NotFound: description: Resource not found content: application/json: schema: $ref: '#/components/schemas/Error' securitySchemes: BearerAuth: type: http scheme: bearer description: JWT token obtained from POST /admin/login ApiKeyHeader: type: apiKey in: header name: X-API-Key description: | Client API key (prefixed with `sk_`). On `/api/*` endpoints the key is scoped to its own MT5 accounts. On `/admin/*` endpoints the key identifies its **owning admin** and grants access to all of that admin's keys — so any of your `sk_` works to manage any of your other keys (cross-admin operations are rejected as `400 Key not found`). ````