> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dataerai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Post apiallocations



## OpenAPI

````yaml /api-reference/openapi.yaml post /api/allocations/
openapi: 3.0.3
info:
  title: Console API
  version: 1.0.0
  description: Central control plane API for the Dataerai platform.
servers:
  - url: https://{server}
    description: Your Dataerai deployment (the API is served under /api)
    variables:
      server:
        default: your-deployment.dataerai.com
        description: Host of your Dataerai deployment
security: []
paths:
  /api/allocations/:
    post:
      tags:
        - api
      operationId: allocations_create
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/AllocationCreate'
          application/x-www-form-urlencoded:
            schema:
              $ref: '#/components/schemas/AllocationCreate'
          multipart/form-data:
            schema:
              $ref: '#/components/schemas/AllocationCreate'
        required: true
      responses:
        '201':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Allocation'
          description: ''
      security:
        - cookieAuthCsrfExempt: []
components:
  schemas:
    AllocationCreate:
      type: object
      description: |-
        Write-side serializer for provisioning a new Allocation.

        ``is_default`` is intentionally not exposed — admins who want to
        swap an owner's default use ``POST /api/allocations/{id}/default/``
        which atomically flips the partial unique constraint.

        Optional ``parent_id`` creates a sub-Allocation carved from the named
        parent. When supplied, ``repository_id`` is ignored (the view
        inherits the parent's repository) and the caller must own the
        parent directly. Thin-provisioning means no sum-check against the
        parent's remaining headroom at creation — capacity is enforced at
        upload time.
      properties:
        owner_type:
          $ref: '#/components/schemas/AllocationOwnerTypeEnum'
        owner_id:
          type: string
          format: uuid
        repository_id:
          type: string
          format: uuid
        parent_id:
          type: string
          format: uuid
          nullable: true
        data_volume_limit:
          type: integer
          minimum: 1
        max_records:
          type: integer
          minimum: 1
        alias:
          type: string
          maxLength: 255
        attach_to_asset_id:
          type: string
          format: uuid
          nullable: true
        attach_to_collection_id:
          type: string
          format: uuid
          nullable: true
      required:
        - data_volume_limit
        - max_records
    Allocation:
      type: object
      properties:
        id:
          type: string
          format: uuid
          readOnly: true
        repository_id:
          type: string
          format: uuid
          readOnly: true
        repository_name:
          type: string
          readOnly: true
        owner_user:
          allOf:
            - $ref: '#/components/schemas/User'
          readOnly: true
        owner_project:
          allOf:
            - $ref: '#/components/schemas/AllocationProject'
          readOnly: true
        owner_project_id:
          type: string
          format: uuid
          readOnly: true
          nullable: true
        owner_organization_id:
          type: string
          format: uuid
          readOnly: true
          nullable: true
        parent_id:
          type: string
          format: uuid
          readOnly: true
          nullable: true
        children_count:
          type: integer
          readOnly: true
        alias:
          type: string
          readOnly: true
        data_volume_limit:
          type: integer
          readOnly: true
        max_records:
          type: integer
          readOnly: true
        remaining_data_volume_limit:
          type: integer
          readOnly: true
        remaining_max_records:
          type: integer
          readOnly: true
        current_bytes:
          type: integer
          readOnly: true
        current_record_count:
          type: integer
          readOnly: true
        is_default:
          type: boolean
          readOnly: true
        pooled:
          type: boolean
          readOnly: true
        created_at:
          type: string
          format: date-time
          readOnly: true
        updated_at:
          type: string
          format: date-time
          readOnly: true
      required:
        - alias
        - children_count
        - created_at
        - current_bytes
        - current_record_count
        - data_volume_limit
        - id
        - is_default
        - max_records
        - owner_organization_id
        - owner_project
        - owner_project_id
        - owner_user
        - parent_id
        - pooled
        - remaining_data_volume_limit
        - remaining_max_records
        - repository_id
        - repository_name
        - updated_at
    AllocationOwnerTypeEnum:
      enum:
        - project
        - user
        - organization
      type: string
      description: |-
        * `project` - project
        * `user` - user
        * `organization` - organization
    User:
      type: object
      description: |-
        Resolve ``user.person`` once per serialization pass.

        ``user.person`` memoizes per instance, but distinct users in a list are
        distinct instances — so a list serializer would still issue one
        ``Person`` query per row. When used ``many=True`` this mixin routes
        through :class:`_PersonReadThroughListSerializer`, which calls
        ``User.attach_persons`` to batch the whole page into a single query;
        the per-render ``context`` cache below then dedups the name+email
        double-read for each user.

        The context cache lives only for the lifetime of the serializer tree,
        so one ``.data`` render resolves each distinct user's ``Person`` at
        most once and re-batches fresh on the next render.
      properties:
        id:
          type: string
          format: uuid
          readOnly: true
        email:
          type: string
          readOnly: true
        name:
          type: string
          readOnly: true
        is_system_admin:
          type: boolean
          readOnly: true
        is_repository_admin:
          type: boolean
          readOnly: true
        date_joined:
          type: string
          format: date-time
          readOnly: true
      required:
        - date_joined
        - email
        - id
        - is_repository_admin
        - is_system_admin
        - name
    AllocationProject:
      type: object
      properties:
        id:
          type: string
          format: uuid
          readOnly: true
        name:
          type: string
          readOnly: true
      required:
        - id
        - name

````