Run Ollama on your computer, install a model, and send a POST request to http://localhost:11434/api/chat with the model name and a messages array. Start with stream: false so you can inspect one complete JSON response. Add streaming or conversation history once that first request works.
Establish a local baseline
First make sure you can run a model with the Ollama command line. Use ollama list to find the exact installed model tag. Try a short prompt and confirm that it answers. If you are starting from scratch, our local AI setup guide explains how to choose and install a model. A working command-line prompt gives you a baseline before adding an HTTP client. It also helps you distinguish an unavailable model from a request that never reached the server.
For the first API test, use the same computer and keep the endpoint on its local loopback address. If the connection is refused, confirm Ollama is running and that the client is actually running on the same host. A container or virtual machine can have its own loopback interface. Use the runtime’s supported networking setup when needed. Keep the experiment local while learning the request format so you do not inadvertently expose a model endpoint on your network.
Send a complete JSON request
Send a POST to the chat endpoint with the JSON content type. A minimal request body is {"model":"YOUR_INSTALLED_TAG","messages":[{"role":"user","content":"Give me one example of a local backup."}],"stream":false}. Replace the placeholder with the installed tag. Use an HTTP client you already have, or save the JSON as request.json and use curl -H "Content-Type: application/json" --data-binary @request.json http://localhost:11434/api/chat. In Windows PowerShell, use curl.exe if your shell resolves curl to a different command. The Ollama chat endpoint reference documents the request fields and response.
Inspect the HTTP status and the returned JSON. For a normal nonstreaming answer, read the assistant content inside the message object. Do not assume that every response contains that object. Handle server errors before reading nested fields, and log a short diagnostic that avoids including private prompt text. If the server reports the model is missing, compare the request with the exact name from the local list. If it reports malformed JSON, check the saved file for quoting problems before changing any model options.
Send the history you want the model to use
For a follow-up, include the earlier user message, the assistant reply and the new user message in order. The client is responsible for assembling the context it wants to send. Keep a record of roles and content, rather than concatenating everything into a single ambiguous prompt. Test with a distinctive detail from the first turn and a simple follow-up that depends on that detail. If the model cannot use it, inspect the request body to confirm the previous messages are included.
Keep the history relevant. Long transcripts can consume more context and increase processing time. If you remove or summarize old turns, preserve any facts or instructions the next answer depends on. Our Ollama context length guide describes a controlled test for checking how much useful text reaches the model. Use representative input rather than assuming a successful two-message example will scale to long sessions without changes.
Add streaming when it benefits the interface
With streaming enabled, the server can deliver successive JSON records as the answer is generated. Read them incrementally and accumulate the assistant text for display or later use. Treat a network chunk as a transport detail. Buffer incoming bytes until you have a complete record before parsing it. Check the final record before declaring success. If the connection closes early, mark the answer as incomplete so your interface does not present a truncated reply as finished.
Use nonstreaming mode when the application only needs the final response and incremental display adds no value. It is also a simpler first step for validating structured output. Our structured JSON guide covers requesting a schema and validating the completed content. In either mode, handle cancellation and timeouts at the client. A person closing the window or sending a new request should not leave the interface reporting that the original answer is still coming.
Separate startup delay from generation time
Run the same request twice and compare the first request with a follow-up while the model is still loaded. The API supports a keep_alive setting that controls how long the model remains loaded after a request. Set it intentionally if your workflow repeatedly calls the same model or shares limited memory with other applications. Use the endpoint documentation for supported values. Keeping a model ready can reduce the wait for the next prompt, while retaining it consumes memory that another task might need.
Compare prompts of similar length and the same model options. A long message history can increase processing even if the requested answer is short. If a model takes too much memory or runs slowly, our quantization guide explains how to compare variants under the same workload. Record what changed. If a restart, model swap and shorter history all happen together, you cannot tell which one improved the response.
Test the errors your client will encounter
Try a request with a model tag that does not exist and another that deliberately omits a required field. Confirm the client shows a clear error and can then send a valid request. For an interactive app, test closing a stream and starting a second one. Do not let a partial first reply appear as part of the second conversation. Keep logs limited to status codes, timing and the model tag unless the user has deliberately chosen to retain prompt content.
Save a small known-good request beside your project so you can run it after changing the runtime, model or client. Include one follow-up test and one error case. That gives you a quick way to distinguish a broken connection from a change in answer quality. For an application that handles private material, verify where its logs and client data are written before testing with real documents.
If your application sends several prompts at once, start by observing the behavior of a single request and then repeat with two separate conversations. Give each request its own identifier and keep its response buffer separate. Cancel one request and confirm the other can still finish. If latency rises sharply, capture the timing for each request and compare it with the single-request baseline. That test can reveal queuing or memory pressure that a simple successful reply will never expose.
Frequently asked questions
What is the difference between chat and a single prompt?
The chat endpoint accepts a list of messages with roles. Send the relevant previous messages when the next answer depends on them.
Why does the response fail to parse as one JSON object?
Check whether streaming is enabled. Parse the individual records or set stream to false for a single response.
Why is the first request slower?
Loading a model can add startup time. Compare another request while it remains loaded and check the timing information returned by the endpoint.
