Applications API

Lists applications newest first, at most 500 per page. Names are labels and need not be unique; address an application by id. next_cursor is the position of the last returned row while more rows remain; pass it back as after, with the same filters, for the next page. next_cursor is null on the last page.

Streams one CLI-produced tar.gz directly into bounded durable staging. Metadata is carried in headers so the archive is never base64-wrapped or materialized as JSON by the server.

The proxy in front of the API ends a request it has not answered within about 100 s, so a large archive on a slow uplink fails here; POST /api/applications/uploads sends the archive straight to the object store instead.

Publishes an immutable new release of an owned application using the same bounded tar.gz upload pipeline. If-Match guards the application revision; acceptance increments it, and successful publication increments it again when latest_ready_release changes. Name and application identity are preserved. Existing playlist release pins are not changed.

An identical idempotent retry returns the original operation even after revision changes. The proxy in front of the API ends a request it has not answered within about 100 s, so a large archive on a slow uplink fails here; POST /api/applications/{id}/uploads sends the archive straight to the object store instead.

Declares a direct upload of one CLI-produced tar.gz that creates a new application. The answer is a signed authorization for exactly one object PUT of the archive, so the bytes go straight to the object store and never through the API, whose proxy ends a request it has not answered within about 100 s.

PUT the archive to upload_url, then commit with POST /api/applications/uploads/{id}/commit and wait on the operation. The application, its release and the receiving operation exist from this answer on, as after POST /api/applications. An upload not committed within 24 hours fails, and an application that never published a release is removed.

The same Idempotency-Key and body answer the same upload with a freshly signed URL. GET /api/capabilities sets features.application_direct_uploads where these routes are served.

Declares a direct upload of a new immutable release of an owned application, answered as POST /api/applications/uploads is. If-Match guards the application revision as on POST /api/applications/{id}/releases, and acceptance increments it. The body carries no name; a release keeps its application's name. Existing playlist release pins are not changed.

Commits a direct application upload once its PUT has finished. The server checks the staged archive against the declaration (its size and the SHA-256 checksum the object store took with the PUT), copies it into its own upload staging and queues publication.

Wait on the returned Operation with GET /api/operations/{id} until it is succeeded or failed, as after POST /api/applications. A commit before the PUT finished answers invalid_request and changes nothing, so it can be sent again; staged bytes that differ from the declaration fail the upload. A repeated commit answers the same operation.

Changes the display name of an application owned by the authenticated project. Names are trimmed, contain 1 to 120 Unicode characters with no controls, and may repeat within a project. Application identity, releases, K/V data, and playlist release pins are preserved.

A changed name advances the application revision and emits application.updated; the same name is a no-op. If-Match optionally guards the revision. An identical idempotent retry returns the original response after subsequent metadata changes.

Tombstones one application owned by the authenticated project and all of its releases. The project bearer is authoritative; an unknown or other-project id is not_found. If-Match guards the application revision. A live manifest reference blocks deletion with application_in_use; there is no force-delete path.