Build an n8n Document Q&A Workflow with Human Approval and an OpenAI-Compatible API

The decision: where should approval happen?

For document question answering, do not add human approval merely because an AI model is present. Add it at the point where the workflow could access sensitive material or publish an answer that needs review.

A useful n8n design is:

1. Receive a question.
2. Ask an AI Agent to prepare a document-search request.
3. Pause for human approval before the search tool runs when the corpus is sensitive, the query could expose restricted material, or the search has operational cost.
4. Retrieve passages with source metadata.
5. Ask the model to answer only from those passages.
6. Return an answer with source references, or route the draft to a second approval step before publication.

This separates three decisions that are often confused: whether the question is acceptable, whether the retrieval action is acceptable, and whether the generated answer is ready to send.

n8n documents human review for specific tools connected to an AI Agent. When review is enabled, the workflow pauses and a reviewer can approve or deny the proposed tool call. See the n8n human-in-the-loop documentation for the supported behavior and approval-channel details.

Prerequisites

You need:

• An n8n workflow with an AI Agent and a model connection.
• A searchable document source, such as a vector store, database, or internal search service. The exact connector is application-specific and is not established by the cited n8n page.
• A retrieval tool that returns text together with document metadata.
• An approval channel configured in n8n. The documentation lists Chat, Slack, Discord, Telegram, Microsoft Teams, Gmail, WhatsApp Business Cloud, Google Chat, and Microsoft Outlook as available channels.
• Access to an OpenAI-compatible API endpoint. OneMux provides access to leading AI models through one OpenAI-compatible API; use the OneMux quickstart and API documentation for the current endpoint and authentication instructions.

Compatibility is conditional. Before connecting n8n, confirm that the selected endpoint supports the request format, model identifier, authentication method, streaming behavior, tool calling, and parameters your n8n node or HTTP request uses. This article does not claim that a particular OneMux model or n8n configuration has been tested.

Recommended n8n workflow structure

Create the workflow as five logical stages:

1. Capture and normalize the question

Use your chosen n8n entry point to receive a question and normalize it into a small object containing the user question, user or workspace context, and an optional document-scope filter.

Do not place unrestricted user text directly into a system instruction. Keep the question as data and define the agent's behavior separately. If the workflow supports tenant or department boundaries, pass those boundaries to the retrieval tool as controlled fields rather than allowing the model to invent them.

2. Add a document-search tool

Connect a search tool to the AI Agent. Its input should be narrow and explicit, for example:

{
  "query": "string",
  "document_scope": "string or controlled value",
  "max_results": "integer"
}

The search result should preserve enough metadata for a useful citation:

{
  "text": "Approved passage from the document",
  "title": "Document title",
  "url": "Document URL or stable identifier",
  "page": "Page number when available",
  "section": "Section heading when available",
  "chunk_id": "Stable passage identifier"
}

The field names above are an implementation pattern, not a claim about a required n8n schema. Adapt them to the connector or service you use. The important property is traceability: the answer generator must receive the passage and its origin together.

3. Put human review around the selected tool

Open the AI Agent's Tools panel, find the Human review section, choose an approval channel, and connect the document-search tool to that review step. Configure the selected channel's credentials and settings in n8n.

A reviewer message can expose the proposed action and its parameters. n8n's documentation describes the $tool.name and $tool.parameters variables for this purpose. A practical message is:

The AI wants to use {{ $tool.name }} with these parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}

Approve only if the query and document scope are appropriate for this request.

This is most useful when the reviewer can identify a risky scope, such as a request that appears to search another team's documents. For ordinary public documentation, approval on every search may create unnecessary friction. In that case, keep retrieval automatic and place approval on a separate tool that publishes or sends the final answer.

4. Connect the OpenAI-compatible model endpoint

Configure the model layer using the endpoint and credentials documented by your provider. With OneMux, start from the OneMux quickstart, select a model that supports the capabilities your n8n node requires, and verify the model identifier and request parameters.

A generic request shape may look like this, but it is illustrative rather than a tested OneMux recipe:

curl https://api.example-provider.invalid/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR_MODEL_ID",
    "messages": [
      {"role": "system", "content": "Answer only from supplied document passages."},
      {"role": "user", "content": "What does the document say about retention?"}
    ]
  }'

Replace the placeholder URL, key handling, and model ID with values from the provider's current documentation. Do not expose credentials in workflow exports or user-visible approval messages. If n8n's model node expects a parameter that the endpoint does not support, use a compatible configuration or an HTTP Request-based design only when your security and response parsing requirements are satisfied.

5. Enforce attribution in the answer prompt

Give the model the retrieved passages in a clearly delimited context and require a citation for every substantive claim. For example:

You answer questions about the supplied documents.

Rules:
- Use only the passages in DOCUMENT_CONTEXT.
- If the passages do not support an answer, say that the documents do not establish it.
- Do not create titles, URLs, page numbers, or quotations.
- Cite each factual answer using the supplied title and page, section, URL, or chunk ID.
- Distinguish a direct statement from an inference.

DOCUMENT_CONTEXT:
{{ JSON.stringify($json.documents) }}

QUESTION:
{{ $json.question }}

The exact expression syntax depends on how your preceding n8n nodes shape the data. Treat this prompt as a pattern, not a drop-in workflow export.

Approval design: retrieval versus publication

There are two sensible approval points:

You can also use both for high-risk workflows. n8n's documentation states that review can apply to all tools connected to an AI Agent or to selected tools, which supports this selective design. It also notes that approval can happen through a different channel from the main interaction; for example, a user-facing chat can be paired with reviewer approval in Slack.

System prompt and denial behavior

Tell the agent which tools require approval and what denial means. If a reviewer denies the search, the agent should not retry the same call with altered wording or claim that it found evidence. It should explain that the requested lookup was not approved and offer a narrower, permitted alternative when one exists.

A concise policy is:

The document_search tool requires human approval. If it is denied, do not call it again for the same request. Tell the user that the lookup was not approved. Never answer from memory when document evidence is required.

This follows n8n's documented guidance to include tool and human-review behavior in the system prompt so the agent can handle rejected calls appropriately.

Troubleshooting and limitations

The approval request lacks useful context

Check that the tool inputs use explicit fields and that the review message includes $tool.name and $tool.parameters. Avoid hiding the important scope inside an opaque string.

Citations are missing

Inspect the retrieval output before it reaches the model. If title, URL, page, section, or chunk identifiers are dropped by a mapping node, the model cannot reliably reconstruct them. Also instruct the model to refuse unsupported claims.

The endpoint rejects the request

Verify the base URL, authentication header, model ID, tool-calling support, context limits, and parameter names. OpenAI-compatible does not mean identical: compatibility must be checked against both n8n's request format and the provider's documented API.

Denial causes an awkward response

Add an explicit denial policy to the system prompt and test both approval and denial paths. n8n documents approval and cancellation as separate outcomes; your workflow should handle both rather than assuming the tool always runs.

The workflow is too slow

Use selective review instead of approving every low-risk search. Keep approval for sensitive retrieval or publication, and measure the operational effect in your own environment. Do not assume model speed, retrieval quality, or approval latency without testing.

Cost and operational planning

OneMux is relevant here as a model-access route, not as a replacement for n8n's workflow controls. Review the current OneMux pricing before choosing a model, and account for input and output usage, retrieval volume, repeated approval attempts, and any document-search service costs. The applicable price depends on the selected model and current published terms; this article does not assign a rate or promise savings.

For spend visibility and model selection context, browse the OneMux model catalogue. Keep the model choice conditional on the capabilities your workflow actually needs, especially structured output or tool calling.

Conclusion

A robust n8n document Q&A workflow is not just an agent connected to a model. It is a controlled chain: retrieve authorized passages, preserve their metadata, require review at the right tool boundary, and generate an answer that cites only the evidence it received.

Use n8n for orchestration and human approval, and evaluate OneMux as a practical OpenAI-compatible model-access route when its documented endpoint and parameters match your design. Start with a small corpus, test approved and denied paths, and treat unsupported claims, missing citations, and incompatible parameters as workflow failures rather than model mysteries.

Sources

• n8n: Human-in-the-loop for tools — source for tool approval behavior, approval channels, $tool expressions, and denial-handling guidance.
• OneMux documentation — provider documentation for current API usage and compatibility details.
• OneMux quickstart — starting point for endpoint and authentication configuration.
• OneMux pricing — current pricing reference to check before deployment.