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

# Publish a data app (api kind one-step publish)

> **Deprecated**: submissions now go through the portal's contract
import wizard (backed by POST /data-apps/contract/assemble) or the
three-step chain (workspace → builds → releases). Kept for the
built-in console and existing tests; removal will be scheduled
separately.

One-step publish sugar for api kind (declarative integration):
internally an atomic chain of create identity → save Workspace →
freeze Build → promote Release; submitting is publishing.

**The version number is fixed by the publish action**: default =
patch+1 over the current largest Release (0.1.0 for the first); the
submission need not and does not carry a version (identity.version
is ignored on this path). To specify a version explicitly
(expressing a major/minor bump), use the three-step chain's
POST /data-apps/{ref}/releases.
code kind (code packages) does not use this sugar: image builds are
async, so "submit = published" does not hold — follow the
three-step chain (PUT workspace → POST builds → poll until ready →
POST releases).

The namespace is inferred from authentication: identity.app_name in
the manifest carries only the app name (no prefix of any kind), and
the app lands under the publisher's own (user, app name) — the
package is author-uploaded text that could say anything; the only
proof of identity is which key you publish with. Same-named apps
across users coexist naturally, and there is no namespace
declaration slot to impersonate.
The app identity (app_id) is minted exactly once; renaming the user
or the app never changes it. External references are always the
two-part `<namespace>/<app_name>` form. Releases are immutable:
publishing again appends a new version, old versions are never
overwritten, and runs in flight or historical references pinned to
old versions are unaffected by a publish.
Two name gates precede publishing: the account must have a username
(without one the two-part reference is unreachable and nobody could
call the published app, 400); and the historical ownership of
(username, app name) must be yours — after a username changes
hands, app names used by the previous holder enter a freeze
(30 days from when the platform first observes the handover) and
cannot be reused within it (409), protecting stray external
references from takeover.



## OpenAPI

````yaml /jp/datahub/api/openapi.json post /v1/data-apps
openapi: 3.1.0
info:
  title: DataHub API
  version: 0.2.0
  description: Public /v1 contract of Octoparse DataHub. Internal channels are excluded.
servers:
  - url: https://api-datahub.octoparse.com
security:
  - bearerAuth: []
tags:
  - name: Discovery
    description: >-
      Anonymous access: platform metadata (currency), data app search, detail
      and input contract, machine-readable manifest spec.
  - name: Publishing
    description: >-
      Self-service publishing channel (API Key auth), two-phase: validate first
      (validate / package, nothing persisted), then publish (POST /data-apps,
      the submission goes live as a new Release). api kind (declarative
      integration) becomes visible on publish; code kind (code package) returns
      202 and enters an async image build; once ready it is promoted to a
      Release, visible and runnable. Poll progress via GET
      /data-apps/{ref}/builds.
  - name: Runs & Results
    description: >-
      Start / query / cancel runs and read result records with pagination.
      Business inputs go in the request body; platform run options (wait,
      max_records) go in query parameters.
  - name: Datasets
    description: >-
      Metadata and record access for platform datasets (including seeded stock
      data).
  - name: Account
    description: Account info and cumulative usage for the current API Key.
  - name: Secrets
    description: >-
      CRUD for upstream credentials (environment entries referenced by manifest
      `runtime.env`). Plaintext is write-only: every read returns a mask.
paths:
  /v1/data-apps:
    post:
      tags:
        - Publishing
      summary: Publish a data app (api kind one-step publish)
      description: |-
        **Deprecated**: submissions now go through the portal's contract
        import wizard (backed by POST /data-apps/contract/assemble) or the
        three-step chain (workspace → builds → releases). Kept for the
        built-in console and existing tests; removal will be scheduled
        separately.

        One-step publish sugar for api kind (declarative integration):
        internally an atomic chain of create identity → save Workspace →
        freeze Build → promote Release; submitting is publishing.

        **The version number is fixed by the publish action**: default =
        patch+1 over the current largest Release (0.1.0 for the first); the
        submission need not and does not carry a version (identity.version
        is ignored on this path). To specify a version explicitly
        (expressing a major/minor bump), use the three-step chain's
        POST /data-apps/{ref}/releases.
        code kind (code packages) does not use this sugar: image builds are
        async, so "submit = published" does not hold — follow the
        three-step chain (PUT workspace → POST builds → poll until ready →
        POST releases).

        The namespace is inferred from authentication: identity.app_name in
        the manifest carries only the app name (no prefix of any kind), and
        the app lands under the publisher's own (user, app name) — the
        package is author-uploaded text that could say anything; the only
        proof of identity is which key you publish with. Same-named apps
        across users coexist naturally, and there is no namespace
        declaration slot to impersonate.
        The app identity (app_id) is minted exactly once; renaming the user
        or the app never changes it. External references are always the
        two-part `<namespace>/<app_name>` form. Releases are immutable:
        publishing again appends a new version, old versions are never
        overwritten, and runs in flight or historical references pinned to
        old versions are unaffected by a publish.
        Two name gates precede publishing: the account must have a username
        (without one the two-part reference is unreachable and nobody could
        call the published app, 400); and the historical ownership of
        (username, app name) must be yours — after a username changes
        hands, app names used by the previous holder enter a freeze
        (30 days from when the platform first observes the handover) and
        cannot be reused within it (409), protecting stray external
        references from takeover.
      operationId: publish_data_app_v1_data_apps_post
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/ManifestSubmission'
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/DataEnvelope_PublishResult_'
        '422':
          description: Validation Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/HTTPValidationError'
      deprecated: true
components:
  schemas:
    ManifestSubmission:
      properties:
        manifest:
          type: string
          title: Manifest
        files:
          additionalProperties:
            type: string
          type: object
          title: Files
        secrets:
          additionalProperties:
            type: string
          type: object
          title: Secrets
      type: object
      required:
        - manifest
      title: ManifestSubmission
    DataEnvelope_PublishResult_:
      properties:
        data:
          $ref: '#/components/schemas/PublishResult'
      type: object
      required:
        - data
      title: DataEnvelope[PublishResult]
    HTTPValidationError:
      properties:
        detail:
          items:
            $ref: '#/components/schemas/ValidationError'
          type: array
          title: Detail
      type: object
      title: HTTPValidationError
    PublishResult:
      properties:
        app_name:
          type: string
          title: App Name
        namespace:
          anyOf:
            - type: string
            - type: 'null'
          title: Namespace
        version:
          type: string
          title: Version
          default: ''
        status:
          type: string
          title: Status
          default: published
        card:
          additionalProperties: true
          type: object
          title: Card
        missing_secrets:
          items:
            type: string
          type: array
          title: Missing Secrets
        name_reused_from:
          anyOf:
            - type: string
            - type: 'null'
          title: Name Reused From
      type: object
      required:
        - app_name
        - card
      title: PublishResult
    ValidationError:
      properties:
        loc:
          items:
            anyOf:
              - type: string
              - type: integer
          type: array
          title: Location
        msg:
          type: string
          title: Message
        type:
          type: string
          title: Error Type
        input:
          title: Input
        ctx:
          type: object
          title: Context
      type: object
      required:
        - loc
        - msg
        - type
      title: ValidationError
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      description: DataHub API Key

````