Calling the Local HTTP API

An API you can call from the terminal

An API (application programming interface) is just an agreed-upon, documented way for two programs to talk to each other - in this case, your code and the Ollama daemon. Ollama's HTTP API listens only on this same machine, at the loopback Internet Protocol (IP) address 127.0.0.1 (a special address that always means "this computer, not the network") on port 11434. You can send it a plain JSON request with curl and get a JSON response back:

$ curl -s http://127.0.0.1:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen2.5:0.5b","prompt":"Reply READY","stream":false}' | jq -r .response
READY

Setting "stream":false tells Ollama to wait until generation is fully finished and then hand back exactly one, complete JSON document - which is easy for a script to parse with a tool like jq (a command-line JSON processor). The alternative, streaming, sends back many small JSON fragments, one per line, as each piece of the answer is generated. Streaming feels much faster in an interactive chat screen because the user sees words appear immediately, but it pushes real work onto your code: you now have to read those fragments one at a time and stitch them back together yourself instead of getting one tidy response.

Tip: Two small curl/jq habits save a lot of debugging time in automation. curl -f makes curl return a failing exit code on an HTTP error instead of silently printing an error page as if it were a normal response. jq -e similarly fails (with a nonzero exit code) when the JSON value it extracts doesn't meet an expected condition, such as being null or empty. Together they turn "the script kept going with garbage data" into "the script stopped and told you something was wrong" - exactly what you want in a pipeline you're not watching in real time.