Summary
omni uploads create can never succeed. The command is generated for a multipart/form-data endpoint and its --schema output shows a file parameter, but the CLI sends the request body as JSON — so the server rejects every invocation.
The OpenAPI spec is correct here — the endpoint declares content: multipart/form-data with file: {type: string, format: binary}, which is the standard OpenAPI 3 encoding for a file part. The CLI reads the body schema but discards the media type it is declared under, so this is a CLI-side consumption bug rather than a spec problem.
POST /api/v1/uploads is currently the only multipart/form-data endpoint in the spec, which is likely why this path was never exercised.
Reproduction
omni uploads create --body '{"file":"/path/to/data.csv","modelId":"<model-uuid>","viewName":"my_view"}'
Observed
{"detail":"Invalid request. Expected multipart/form-data.","status":400}
Error: API returned HTTP 400
There is no --file flag, and no value of file in the JSON body can work — the transport itself is wrong, not the payload.
Expected
The CSV is uploaded and the command returns the created upload (id, viewName, rowCount, viewCreated).
Why it happens
Three things combine:
internal/openapi/generate.go — requestBodySchema() prefers application/json and otherwise falls back to the first declared media type. For this endpoint that's the multipart schema, so the command is generated and --schema renders the file field (type: string, format: binary) as though it were sendable.
internal/auth/auth.go — every request hardcodes Content-Type: application/json.
- There is no multipart machinery anywhere in the CLI (no
mime/multipart use, no file reading for request bodies).
Net effect: the generator emits a command whose declared interface can't be honored by the transport.
Workaround
Call the endpoint directly:
curl -X POST "$OMNI_BASE_URL/api/v1/uploads" \
-H "Authorization: Bearer $OMNI_TOKEN" \
-F "modelId=<model-uuid>" \
-F "viewName=my_view" \
-F "file=@/path/to/data.csv"
Every other step in an upload-backed workflow (creating the draft, patching the tab, publishing) works through the CLI — only this one call has to bypass it.
Environment
- CLI built from
main with a current spec sync
- Reproduced against a current API deployment
Filed by Claude on behalf of @barberscott.
Summary
omni uploads createcan never succeed. The command is generated for amultipart/form-dataendpoint and its--schemaoutput shows afileparameter, but the CLI sends the request body as JSON — so the server rejects every invocation.The OpenAPI spec is correct here — the endpoint declares
content: multipart/form-datawithfile: {type: string, format: binary}, which is the standard OpenAPI 3 encoding for a file part. The CLI reads the body schema but discards the media type it is declared under, so this is a CLI-side consumption bug rather than a spec problem.POST /api/v1/uploadsis currently the onlymultipart/form-dataendpoint in the spec, which is likely why this path was never exercised.Reproduction
omni uploads create --body '{"file":"/path/to/data.csv","modelId":"<model-uuid>","viewName":"my_view"}'Observed
There is no
--fileflag, and no value offilein the JSON body can work — the transport itself is wrong, not the payload.Expected
The CSV is uploaded and the command returns the created upload (
id,viewName,rowCount,viewCreated).Why it happens
Three things combine:
internal/openapi/generate.go—requestBodySchema()prefersapplication/jsonand otherwise falls back to the first declared media type. For this endpoint that's the multipart schema, so the command is generated and--schemarenders thefilefield (type: string, format: binary) as though it were sendable.internal/auth/auth.go— every request hardcodesContent-Type: application/json.mime/multipartuse, no file reading for request bodies).Net effect: the generator emits a command whose declared interface can't be honored by the transport.
Workaround
Call the endpoint directly:
Every other step in an upload-backed workflow (creating the draft, patching the tab, publishing) works through the CLI — only this one call has to bypass it.
Environment
mainwith a current spec syncFiled by Claude on behalf of @barberscott.