Ollama structured output in n8n: get usable JSON from a local model

If Ollama and n8n are already connected, the next problem is usually not the connection. It is the shape of the response.

A local model may return a paragraph instead of JSON, omit a field, use "high" where your workflow expects "urgent", or wrap otherwise-valid JSON in a sentence. That is enough to break a Google Sheets row, a task-board card, or the next n8n node.

The practical fix is to treat the model response as an output contract. Define the fields, allowed values, and required types. Ask Ollama for that shape, parse it in n8n, validate the values, and stop for review when the result does not meet the contract.

This is for beginners who already have an Ollama and n8n workflow working at a basic level and now want an answer they can safely use in later nodes. The example is intentionally ordinary: turn a rough request into a small record with a category, urgency, confidence, next action, and review flag.

If Ollama itself is new to you, start with what Ollama is or the Ollama tutorial for beginners. The workflow below focuses on output reliability, not model selection.

The workflow in one sentence

The flow is:

Manual input -> Ollama local model -> JSON Schema or Structured Output Parser -> field and value validation -> human review or safe stop -> downstream output

The important part is what happens between the model and the side effect. Do not send raw model text directly to a task board, spreadsheet, document, email, or API. Parse it first, check it, and make the decision to continue explicit.

Copyable workflow contract for n8n

Use this small contract as a starting point. It is deliberately narrow. A smaller schema gives you fewer ways for a response to drift.

JSON Schema

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "WorkflowTaskClassification",
  "type": "object",
  "additionalProperties": false,
  "required": [
    "category",
    "urgency",
    "confidence",
    "next_action",
    "review_required"
  ],
  "properties": {
    "category": {
      "type": "string",
      "enum": ["admin", "technical", "content", "sales", "other"]
    },
    "urgency": {
      "type": "string",
      "enum": ["low", "normal", "high"]
    },
    "confidence": {
      "type": "number",
      "minimum": 0,
      "maximum": 1
    },
    "next_action": {
      "type": "string",
      "minLength": 1
    },
    "review_required": {
      "type": "boolean"
    }
  }
}

Sample input

Please check whether the new landing-page copy has the pricing section and send the approved version to the content board. If anything is missing, flag it for review instead of sending it.

Expected output

{
  "category": "content",
  "urgency": "normal",
  "confidence": 0.94,
  "next_action": "Check the landing-page copy for a pricing section, then send it to the content board only if approved.",
  "review_required": true
}

The exact wording of next_action can vary. The rest of the object should not drift. category and urgency must use one of the listed values, confidence must be between 0 and 1, and review_required must be a Boolean.

n8n node and configuration guidance

The labels in your n8n version may differ slightly, but the roles are the same. Start with a Manual Trigger and a Set or Edit Fields node, then pass one text field such as request_text to the model. Use the Ollama Chat Model node or an Ollama-backed model in your AI chain, and make sure the base URL matches where Ollama actually runs.

The frustrating part is usually the network boundary, not the prompt. If n8n runs in Docker Desktop while Ollama runs on the host, localhost inside the container may point at the container instead of your Mac or PC. In that setup, http://host.docker.internal:11434 is commonly the right starting point. Linux Docker setups may need an explicit host mapping. Check the official n8n integration notes for the environment you are using.

Once the model can respond, put the schema in the prompt and in the structured-output configuration. Tell the model to return one JSON object, with no Markdown fence and no commentary. Then validate the values in n8n before anything writes to Sheets, a task board, or another destination.

The practical node roles look like this:

1. Manual input: Provide the rough request as request_text.
2. Ollama Chat Model: Use the correct base URL for your runtime boundary.
3. Structured response instructions: Include the schema in the prompt and ask for one raw JSON object.
4. Choose a parsing path: Either ask Ollama for JSON or JSON Schema output and then validate it, or send the model through n8n's Structured Output Parser. The parser is based on JSON Schema and can use a manually defined schema or one generated from an example.
5. Validate values: Schema validation checks the structure and basic types. Add an IF or Code node for workflow rules, such as confidence >= 0.75, review_required === true when the request asks for an external action, or a permitted category list if you use a separate validation step.
6. Review or safe stop: Route review_required: true to a human approval step. Route missing, malformed, or out-of-range data to an error branch. Do not let the normal success branch continue merely because the model returned parseable JSON.
7. Downstream output: Only after validation should you write to Google Sheets, a task board, or another destination. Store the original request and the validated record together so a reviewer can see what produced the decision.

For a larger workflow, the n8n error-handling guide for AI workflows is the natural companion. The AI output review checklist is useful when a person needs to approve the result before a side effect.

JSON mode and schema mode are different

It helps to separate two ideas that are often called "structured output."

JSON mode asks for valid JSON. It can stop a model from returning a prose paragraph, but it does not necessarily enforce your field names, required fields, enum values, or numeric limits.

JSON Schema mode describes the object you expect. Ollama supports JSON and JSON Schema through its format option, including required fields and types. n8n's Structured Output Parser also uses a JSON Schema-based definition.

Schema mode is the better starting point when later nodes depend on a stable shape. It still is not a correctness guarantee. A response can satisfy the schema and contain a poor classification, an unhelpful action, or a confident-sounding mistake. That is why the workflow has a second validation layer and a review route.

If you only need a small object and can validate it immediately, a direct Ollama JSON Schema response may be enough. If you are using an n8n AI chain and want the output represented as a parser step, use the Structured Output Parser. In agent scenarios, n8n notes that attaching the parser directly to an agent can be unreliable. A separate LLM chain for the final structured response is often the more consistent arrangement.

Prompt the model around the contract

The schema is not a replacement for clear instructions. A compact prompt can make the expected behavior easier for the model to follow:

Convert the rough request into the JSON object described below.

Return exactly one JSON object. Do not use Markdown fences. Do not add commentary.
Use only the listed enum values.
Set review_required to true when the request involves an external action,
approval, or uncertainty that a person should resolve.
Keep confidence between 0 and 1. Confidence is an estimate, not proof.

JSON Schema:
[PASTE THE SCHEMA HERE]

Rough request:
[INSERT request_text HERE]

Keep the instruction about review in the prompt, but enforce it in n8n when you can. A prompt tells the model what to do. A validation branch decides whether the workflow is allowed to proceed.

A worked example: what the workflow should do

Suppose the input is:

The invoice export is missing two rows. Compare this month's file with the previous export and tell me what changed. Do not update the accounting system until someone checks it.

A reasonable record would be:

{
  "category": "technical",
  "urgency": "normal",
  "confidence": 0.82,
  "next_action": "Compare the current and previous invoice exports, document the two missing rows, and wait for human review before any accounting-system update.",
  "review_required": true
}

That record is useful because it gives the next node explicit values to inspect. The review_required flag also prevents an ambiguous model response from silently becoming an accounting-system change.

The example above is ILLUSTRATIVE / NOT_RUN. This example is a design target, not proof that your own workflow will pass. Run the schema in a harmless test workflow and inspect the parser and validation branch before connecting a side effect.

Worked example record

The expected result is a parsed object with every required field, review_required: true, and no downstream accounting-system update before approval. The actual result for your environment is still NOT_RUN until you run it in a harmless workflow. Treat the example as ILLUSTRATIVE, then keep your own execution ID, parser result, and validation notes when you test it.

Your next action is simple: copy the schema into a harmless test workflow, run the sample input, inspect the parser and validation branches, and record what actually happened before connecting a side effect.

Validate more than parseability

A parser answers, "Can this response be read as the expected data shape?" Your workflow still needs to answer, "Is this record acceptable for this action?"

Useful checks include required fields, allowed category and urgency values, a confidence number between 0 and 1, a non-empty next_action, and review_required: true for actions that need approval. Also check that the model did not smuggle in a destination or instruction your workflow never intended to allow, and that the same input has not already been processed.

A Code node can perform the application-specific checks, while an IF node can route the result. Keep the validation branch visible. Hidden assumptions are difficult to debug when a workflow fails later.

A simple failure object can also help downstream handling:

{
  "status": "needs_review",
  "reason": "Structured output passed parsing but confidence was below the workflow threshold.",
  "original_input": "[preserve the original request]",
  "model_output": "[preserve the parsed object for inspection]"
}

Do not use a failure object as permission to continue. It is a record for the review or error path.

Safe failure beats a plausible answer

Plan for at least three failure types:

1. Transport or connectivity failure: n8n cannot reach the local Ollama endpoint. Check whether Ollama is running, whether the URL is correct for your network boundary, and whether the n8n runtime can reach the host.
2. Format failure: the model returns prose, fenced JSON, invalid JSON, or an object that does not match the parser schema. Send it to an error branch or retry with a bounded policy.
3. Semantic failure: the object parses but the values are wrong, incomplete, or unsafe for the next action. Require review or stop.

A retry may help with a transient format failure. It cannot prove that the second answer is correct. Set a small retry limit, preserve each attempt, and make sure a retry does not duplicate a downstream side effect.

Retries and idempotency are separate concerns. If the workflow writes to a task board or sheet, give the item a stable input or request ID and check for an existing record before creating another one. A model-generated title is not a reliable duplicate key. If the same input can arrive twice, handle that case before the side effect node.

For a library of inspectable examples, see the free n8n workflow library. You can use it to compare how a workflow captures inputs, routes errors, and exposes its final action.

Credentials and environment boundaries

"Local" describes where your Ollama server is running. It does not automatically describe every part of the workflow.

Your n8n instance may run on the same machine, in Docker, on another server, or in a hosted environment. The correct Ollama URL and network permissions depend on that arrangement. localhost inside a container refers to the container, not necessarily the host computer. Docker Desktop commonly provides host.docker.internal, while Linux often needs additional host configuration.

The downstream destination has its own credentials and data boundary. A workflow can use a local model and still send the validated result to a cloud spreadsheet or task board. Document that boundary in the workflow notes, and do not place secrets inside the prompt or model output.

Ollama's local API is documented separately from Ollama Cloud. Check the integration and API documentation for the deployment you are actually using. Ollama also notes that its API is not strictly versioned, so check release notes when behavior or configuration matters.

What to record for a trustworthy run

For each execution you may need to review later, retain enough evidence to reconstruct the path: original input, model and Ollama endpoint, schema and prompt version, attempt count, parser input, validation result, human-review status, downstream write status, and the stable ID that prevents duplicates.

Redact sensitive input and output according to your own data-handling rules. Execution evidence is not the same as a model's confidence value. A confidence number is part of the model-produced record; it is not proof that the workflow was correct.

A small design rule for side effects

Keep the side effect at the end of the path, after parsing, validation, and approval. If you cannot explain why a record reached the side-effect node, the workflow is too opaque.

For the example in this article, a safe route looks like this:

Manual input
  -> Ollama
  -> Structured Output Parser
  -> field/value checks
  -> review_required?
       yes -> human review -> approved? -> write destination or stop
       no  -> write destination only when the action is allowed
  invalid -> record failure -> stop

This arrangement does not make the model infallible. It gives the workflow a clear place to refuse an answer.

FAQ

Should I use JSON mode or the n8n Structured Output Parser?

Use JSON mode when valid JSON is all you need and you will validate the object yourself. Use a JSON Schema and the Structured Output Parser when the workflow depends on required fields, types, and allowed values. In either case, add workflow-specific checks after parsing.

Does a JSON Schema prevent hallucinations?

No. It constrains the shape of the response. It does not prove that the values are true, complete, or appropriate for a side effect.

Why does my parser still fail when the model usually returns JSON?

Check that the model is being asked for the exact format, that the parser is attached at the right point in the chain, and that the response does not contain surrounding commentary or unsupported schema features. n8n documents that $ref is not supported in this parser. Agent setups can also be less consistent when the parser is attached directly to the agent rather than used in a separate final-response chain.

Can I use Ollama Cloud with this exact setup?

Do not assume so. Ollama's structured-output documentation currently says Ollama Cloud does not support structured outputs. Check the current documentation before changing the deployment or relying on the same format behavior.

Takeaway

Reliable Ollama output in n8n starts with a small contract, not a longer prompt. Define the schema, ask for that exact shape, parse it, validate the values, and stop before side effects when the result needs review.

Start by copying the schema above into a test workflow with a Manual Trigger. Run it with one harmless sample, inspect the parsed record and validation branch, and only then connect a destination such as Sheets or a task board. For the wider pattern, build a local workflow with a defined output contract.