Call the HTTP API#

Use the public HTTP API for applications and scripts that share a running conda-presto service.

Set the server URL once for the examples:

export CONDA_PRESTO_URL=http://127.0.0.1:8000
curl --fail --silent --show-error "$CONDA_PRESTO_URL/health"

Resolve inline specs with GET#

Let curl encode repeated query parameters:

curl --fail --silent --show-error --get \
  "$CONDA_PRESTO_URL/resolve" \
  --data-urlencode 'spec=python=3.13' \
  --data-urlencode 'spec=numpy' \
  --data-urlencode 'channel=conda-forge' \
  --data-urlencode 'platform=linux-64' \
  | jq

Resolve a JSON request with POST#

Use a JSON body when the request is assembled programmatically:

curl --fail --silent --show-error \
  "$CONDA_PRESTO_URL/resolve" \
  --json '{
    "specs": ["python=3.13", "numpy"],
    "channels": ["conda-forge"],
    "platforms": ["linux-64", "osx-arm64"]
  }' \
  | jq '.[].platform'

Body fields take precedence over matching query parameters. The output format is always selected with the format query parameter.

Upload an environment file#

Send the original bytes and a matching media type:

curl --fail --silent --show-error \
  --data-binary @environment.yml \
  --header 'Content-Type: application/yaml' \
  "$CONDA_PRESTO_URL/resolve?platform=linux-64"

Use filename when a generic YAML media type could describe several installed formats. For an uploaded lockfile, HTTP parsing inspects format and platform metadata only unless you call /transcode. Resolve and review operations that would require package records return HTTP 400.

Accepted raw upload types and the full request schema are listed in HTTP API reference.

Write a lockfile response#

Select an exporter and write the response directly to a file:

curl --fail --silent --show-error \
  --data-binary @environment.yml \
  --header 'Content-Type: application/yaml' \
  "$CONDA_PRESTO_URL/resolve?platform=linux-64&platform=osx-arm64&format=pixi-lock-v6" \
  --output pixi.lock

Exporter responses fail as a whole when one platform cannot be solved. Native JSON instead keeps per-platform errors in the response array.

Capture a content-addressed result#

Inspect the response headers to obtain the relative cache location:

curl --fail --silent --show-error \
  --dump-header response-headers.txt \
  --output solve-result.json \
  --get "$CONDA_PRESTO_URL/resolve" \
  --data-urlencode 'spec=zlib' \
  --data-urlencode 'channel=conda-forge' \
  --data-urlencode 'platform=linux-64'

grep -i '^location:' response-headers.txt

See Configure result caching for persistent storage and retrieval through /r/<hash>.

Inspect the generated API document#

Fetch the generated OpenAPI document:

curl --fail --silent --show-error \
  "$CONDA_PRESTO_URL/openapi.json" \
  --output openapi.json

Note

The generated schema does not describe the manually dispatched request bodies for POST /resolve, POST /preflight, or POST /transcode. Use HTTP API reference for those body contracts. The browser workbench at / is a separate first-party client. The schema at /openapi.json remains JSON for tools and generated clients.

Use Inspect and compare environments for preflight, repair, diff, and explain tasks. Use Transcode lockfiles without solving for CLI or HTTP conversion without a solve.