Bug description
I followed the instructions to fetch the latest OpenAPI schema so that I can use it with Restish. Here's an example Restish configuration for Zipline (put in ~/.config/restish/restish.json):
{
"apis": {
"zipline": {
"base_url": "<url>",
"spec_files": [
"file:///home/<user>/.config/restish/zipline.json"
],
"profiles": {
"default": {
"auth": {
"type": "api-key",
"params": {
"in": "header",
"name": "Authorization",
"value": "<token>"
}
}
}
}
}
}
}This allows you to invoke Zipline's API endpoints fully from the command-line:
% restish zipline
auth
...
get-api-user GET /api/user
...
post-api-upload POST /api/upload
post-api-upload-partial POST /api/upload/partial
...
Additional Commands:
...
get-api-user-urls GET /api/user/urls
...
For example:
% restish zipline get-api-user-urls
[
{
"code": "<code>",
"createdAt": "2026-07-30T10:57:14.773Z",
"destination": "<url>",
"enabled": true,
"id": "<id>",
"maxViews": null,
"updatedAt": "2026-07-30T11:03:44.875Z",
"userId": "<user-id>",
"vanity": "<vanity>",
"views": 2
}
]
The problem is that the routes for post-api-upload and post-api-upload-partial don't contain appropriate descriptions of the request body, so Restish doesn't know how to invoke these endpoints properly:
% cat zipline.json | jq '.paths."/api/upload".post.requestBody'
null
Compare this with the description of post-api-user-urls:
% cat zipline.json | jq '.paths."/api/user/urls".post.requestBody'
{
"required": true,
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"vanity": {
"nullable": true,
"type": "string",
"minLength": 1,
"maxLength": 100
},
"destination": {
"type": "string",
"minLength": 1,
"format": "uri"
},
"enabled": {
"type": "boolean"
}
},
"required": [
"destination"
]
}
}
}
}
It would be great if the endpoint could be updated with the correct description.
Additionally, please consider adding the instructions for fetching the OpenAPI spec to a more visible place (I was quite lucky to stumble upon that release description). It would also be a good idea to host the spec on the official Zipline webpage since GitHub doesn't allow downloading job artifacts unless you're logged in (this also took me a while to figure out as the artifact item is silently not clickable if you're not logged in).
Even better, it would be best if the Zipline server itself could serve the OpenAPI spec at /api/openapi.json. This is a common practice for OpenAPI-based REST APIs and would allow tools like Restish to dynamically discover the available endpoints for a particular Zipline instance without having to be configured with an explicit OpenAPI spec.
Many thanks for this great project!
How is Zipline being run?
On docker (docker, docker compose, etc.)
Zipline Version
4.6.5
If applicable, what browsers are you seeing this issue on?
No response
Relevant Logs
No response
Steps to Reproduce
No response
Bug description
I followed the instructions to fetch the latest OpenAPI schema so that I can use it with Restish. Here's an example Restish configuration for Zipline (put in
~/.config/restish/restish.json):{ "apis": { "zipline": { "base_url": "<url>", "spec_files": [ "file:///home/<user>/.config/restish/zipline.json" ], "profiles": { "default": { "auth": { "type": "api-key", "params": { "in": "header", "name": "Authorization", "value": "<token>" } } } } } } }This allows you to invoke Zipline's API endpoints fully from the command-line:
For example:
The problem is that the routes for
post-api-uploadandpost-api-upload-partialdon't contain appropriate descriptions of the request body, so Restish doesn't know how to invoke these endpoints properly:Compare this with the description of
post-api-user-urls:It would be great if the endpoint could be updated with the correct description.
Additionally, please consider adding the instructions for fetching the OpenAPI spec to a more visible place (I was quite lucky to stumble upon that release description). It would also be a good idea to host the spec on the official Zipline webpage since GitHub doesn't allow downloading job artifacts unless you're logged in (this also took me a while to figure out as the artifact item is silently not clickable if you're not logged in).
Even better, it would be best if the Zipline server itself could serve the OpenAPI spec at
/api/openapi.json. This is a common practice for OpenAPI-based REST APIs and would allow tools like Restish to dynamically discover the available endpoints for a particular Zipline instance without having to be configured with an explicit OpenAPI spec.Many thanks for this great project!
How is Zipline being run?
On docker (docker, docker compose, etc.)
Zipline Version
4.6.5
If applicable, what browsers are you seeing this issue on?
No response
Relevant Logs
No response
Steps to Reproduce
No response