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

# Register a new user

> Creates a new user account and a personal team. A verification email is sent
automatically — the user must verify their email before logging in.

The same 201 + `{is_success: true}` envelope is returned whether the email
is new or already registered, so this endpoint cannot be used to enumerate
accounts. A verification email is only sent when the address is new or
belongs to an unverified account.




## OpenAPI

````yaml /api-reference/core-openapi.yaml post /auth/register
openapi: 3.0.3
info:
  title: Cyberun API
  version: 1.0.0
  description: >
    Multi-tenant GPU orchestration platform for enterprise private deployments.


    ## Authentication


    Two authentication families are supported:


    - **JWT Bearer** (`Authorization: Bearer <jwt>`) — Used by team
    owners/admins/members
      for management endpoints and user sessions. JWT-authenticated requests that operate
      on a team **must** include the `X-Team-ID` header to select which team the request
      applies to (a user can belong to multiple teams).
    - **Credential Bearer** (`Authorization: Bearer <sk-/ak-/dk-...>`) — Unified
    machine
      credential. The credential is always scoped to a single team derived from the
      credential row, and any `X-Team-ID` header is **ignored**. The three kinds differ in
      identity and routing:

      | Kind          | Prefix | Identity                  | Allowed surfaces |
      | ------------- | ------ | ------------------------- | --- |
      | `integration` | `sk-`  | Team only                 | Runtime API (`/r/`) + the Web MCP endpoint. Rejected on every management endpoint because the authorization layer needs a user identity and `sk-` has none. |
      | `agent`       | `ak-`  | Team only                 | the platform's WebSocket handshake **only** — rejected by the REST surface at the middleware layer. |
      | `device`      | `dk-`  | Team + user (per-device)  | Runtime API and scoped management endpoints — behaves like a JWT for the underlying user. Issued by the desktop pairing flow only (`POST /desktop/pair/confirm`). |

      the authorization layer runs against the user identity carried by JWT and `dk-`. `sk-` and `ak-`
      bypass the authorization layer; service-layer checks enforce team scope for them.

    Runtime endpoints under `/r/` accept **JWT (with `X-Team-ID`)**, `sk-`, and
    `dk-`.

    `ak-` is rejected at the middleware (it is only meaningful on the the
    platform's WebSocket

    handshake). Scoped management endpoints accept **JWT (with `X-Team-ID`)** or

    `dk-`; `sk-` is rejected on management because the the authorization layer
    authorize layer

    requires a user identity. The Web MCP endpoint accepts `sk-` only.

    Multipart upload endpoints (`/uploads/multipart/*`) remain JWT-only.

    Credential-bearing callers (`sk-`, `dk-`) should use single-part presign

    (`POST /r/files/presign`) instead — that returns a vanilla S3 PUT URL

    (≤ 5 GB by S3, subject to the server's configured request cap; default

    500 MB). Files beyond the cap currently require the JWT-only multipart

    flow.


    ## Task Lifecycle


    Tasks follow this state machine: `pending → waiting → queued → running →
    completed | failed | cancelled`.

    Submit tasks via workflow run endpoints, poll status via GET
    /r/tasks/{taskId},

    and retrieve results via GET /r/tasks/{taskId}/result.


    ## Pagination


    All list endpoints support pagination via `current_page` (default: 1) and
    `per_page`

    (default: 20, max: 100) query parameters. Responses include a `page_meta`
    object

    with `current_page`, `per_page`, and `total_count`.
servers:
  - url: https://core.cyberun.cloud/api/v1
    description: Cyberun Cloud API
security: []
tags:
  - name: Auth
    description: >
      Authentication and account lifecycle: register, login, logout, token
      refresh,

      password reset, and email verification.
  - name: User
    description: |
      Current user profile management: view and update profile, change password.
  - name: Team
    description: >
      Team management: create, update, delete teams, leave, and transfer
      ownership.

      Each user gets a personal team on registration.
  - name: Member
    description: |
      Team member management: list members, update roles, and remove members.
  - name: Invitation
    description: >
      Team invitation management: invite users by email, accept/decline
      invitations,

      list pending invitations, and cancel invitations.
  - name: Credential
    description: |
      Unified credential management: integration keys (`sk-`) for programmatic
      API access, agent keys (`ak-`) for headless workers, and device keys
      (`dk-`) for paired desktop installs. All three share storage and
      revocation flow; the `kind` field selects behaviour.
  - name: DevicePair
    description: >
      Desktop device pairing flow. Three endpoints — start (anonymous),

      confirm (JWT, called from the Cyberun dashboard), poll (anonymous, called
      from

      desktop) — exchange a short user-visible code for a `dk-` credential

      without the user ever typing the secret.
  - name: Workflow
    description: >
      ComfyUI workflow template management: create, update, delete, and list
      workflow templates

      with configurable parameters, labels, timeout, and retry settings.
  - name: Task
    description: |
      Task execution and monitoring: submit workflow runs, poll task status,
      retrieve results, and cancel tasks. Tasks follow the lifecycle:
      `pending → waiting → queued → running → completed | failed | cancelled`.
  - name: Webhook
    description: >
      Webhook management: register HTTPS endpoints to receive event
      notifications

      (task.completed, task.failed) with HMAC-SHA256 signed payloads.
  - name: Container
    description: >
      Container service orchestration: deploy arbitrary Docker containers (vLLM,
      Ollama,

      custom services) to agents, manage lifecycle, and proxy HTTP requests
      through

      the gateway with load balancing.
  - name: CloudProvider
    description: >
      Cloud compute provider management: configure third-party cloud GPU
      provider

      API keys (e.g. ComfyUI Cloud) for teams without local GPU agents, and

      manage automatic cloud fallback settings.
  - name: Notifications
    description: |
      In-app notification center: list, read, and manage notifications
      for status changes and system alerts.
  - name: Agent
    description: >
      Agent monitoring: view connected agents for a team, including their
      status,

      labels, and current task. Data is read from the the platform's runtime
      state.
  - name: Node
    description: |
      Custom node management: upload, register, update, and delete ComfyUI
      custom node packages (zip archives) for team-scoped agents.
  - name: Model
    description: |
      Model management: upload, register, update, and delete AI model files
      (checkpoints, LoRAs, etc.) for team-scoped agents.
  - name: File
    description: >
      File upload for workflow inputs: request presigned upload URLs to stage
      files

      (images, videos, audio) in S3, then reference them as `type: file`
      parameters

      when running workflows.
  - name: Upload
    description: >
      Multipart upload support for large files: initiate, presign parts,
      complete,

      and abort multipart uploads. Used alongside domain-specific presign
      endpoints

      for files exceeding ~100 MB.
  - name: Server
    description: |
      Public server information: registration status and other configuration
      visible to unauthenticated clients.
paths:
  /auth/register:
    post:
      tags:
        - Auth
      summary: Register a new user
      description: >
        Creates a new user account and a personal team. A verification email is
        sent

        automatically — the user must verify their email before logging in.


        The same 201 + `{is_success: true}` envelope is returned whether the
        email

        is new or already registered, so this endpoint cannot be used to
        enumerate

        accounts. A verification email is only sent when the address is new or

        belongs to an unverified account.
      operationId: authRegister
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/AuthRegisterRequest'
      responses:
        '201':
          description: Registration accepted (new or duplicate; caller cannot tell).
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/AuthRegisterResponse'
        '400':
          $ref: '#/components/responses/BadRequest'
components:
  schemas:
    AuthRegisterRequest:
      type: object
      required:
        - first_name
        - last_name
        - email_address
        - user_password
      properties:
        first_name:
          type: string
          minLength: 1
          maxLength: 50
          description: User's first (given) name.
          example: Alice
        last_name:
          type: string
          minLength: 1
          maxLength: 50
          description: User's last (family) name.
          example: Chen
        email_address:
          type: string
          format: email
          description: >-
            Email address used for login and notifications. Must be unique
            across the platform.
          example: alice@example.com
        user_password:
          type: string
          minLength: 8
          maxLength: 128
          description: >-
            Password for the account (8–128 characters, must contain at least
            one uppercase letter, one lowercase letter, and one digit).
          example: P@ssw0rd123
    AuthRegisterResponse:
      type: object
      required:
        - is_success
      properties:
        is_success:
          type: boolean
          description: >-
            Always true when registration succeeds. Check your email to verify
            the account.
          example: true
    ErrorResponse:
      type: object
      required:
        - error_message
      properties:
        error_message:
          type: string
          description: Human-readable error message describing what went wrong.
          example: resource not found
  responses:
    BadRequest:
      description: >-
        Invalid request: missing required fields, validation failure, or
        malformed input.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ErrorResponse'

````