n8n Human Approval Workflow with an OpenAI-Compatible API and JSON Schema Validation

The decision: approve the action, not just the extraction

For invoices, support tickets, forms, and inbound requests, the risky part is often not extracting fields. It is what happens afterward: creating a customer record, changing a status, sending an external message, or deleting data.

A robust n8n design therefore uses three gates:

1. Extraction: an OpenAI-compatible API returns structured data.
2. Validation: n8n checks that the data conforms to a JSON Schema.
3. Approval: an n8n AI Agent can call a consequential tool only after a person approves it.

This keeps malformed data from reaching the reviewer and keeps approved execution separate from model output.

OneMux provides access to leading AI models through one OpenAI-compatible API. You can use it as the model-access route if the endpoint and selected model document support for the request format and parameters required by your n8n configuration. OneMux and n8n integration is not claimed to have been tested here.

Prerequisites

You need:

• An n8n instance with access to the HTTP Request, Code, and, where applicable, AI Agent nodes.
• An approval channel supported by your n8n setup, such as n8n Chat, Slack, Telegram, email, or another documented channel.
• Access to an OpenAI-compatible API. If using OneMux, start with the OneMux quickstart and confirm the current endpoint, authentication method, model identifiers, and supported request parameters in the OneMux documentation.
• A JSON Schema describing the object you want to extract.
• A destination tool, such as a CRM update or message-sending action, that should not run without human review.

Do not assume that every OpenAI-compatible endpoint supports every structured-output feature. Verify support for response_format, JSON Schema, tool calls, and the particular model you select. The OneMux models directory can help you review available model options, but it does not by itself prove support for a specific n8n node configuration.

Recommended n8n workflow

A practical workflow can use these nodes:

1. Webhook or another trigger receives the source text.
2. HTTP Request sends the text to the compatible model endpoint.
3. Code parses and validates the returned object.
4. IF routes invalid results to an error or manual-correction path.
5. AI Agent receives the validated object and has access to a consequential tool.
6. Human review pauses the workflow before that tool runs.
7. Approved tool writes the record or sends the message.

The extraction request should ask for only the fields your workflow needs. A compact example schema for a support request might look like this:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": false,
  "required": ["category", "priority", "summary", "customer_email"],
  "properties": {
    "category": {
      "type": "string",
      "enum": ["billing", "technical", "account", "other"]
    },
    "priority": {
      "type": "string",
      "enum": ["low", "normal", "high", "urgent"]
    },
    "summary": {
      "type": "string",
      "minLength": 1
    },
    "customer_email": {
      "type": "string",
      "format": "email"
    }
  }
}

Configure the OpenAI-compatible request

In the HTTP Request node, use the base URL and authentication instructions from the provider documentation. Do not hard-code a provider-specific URL unless you have verified it for your account and region.

The request shape below is illustrative. Whether response_format and its JSON Schema structure are accepted depends on the endpoint, model, and n8n configuration you choose.

{
  "model": "YOUR_DOCUMENTED_MODEL_ID",
  "messages": [
    {
      "role": "system",
      "content": "Extract the requested fields. Do not guess missing values. Return only an object matching the supplied schema."
    },
    {
      "role": "user",
      "content": "{{$json.source_text}}"
    }
  ],
  "temperature": 0,
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "support_request",
      "strict": true,
      "schema": {
        "type": "object",
        "additionalProperties": false,
        "required": ["category", "priority", "summary", "customer_email"],
        "properties": {
          "category": {"type": "string"},
          "priority": {"type": "string"},
          "summary": {"type": "string"},
          "customer_email": {"type": "string"}
        }
      }
    }
  }
}

The example uses a placeholder model ID deliberately. Select a model documented as compatible with your chosen endpoint. If strict JSON Schema output is unavailable, use a supported JSON mode only if your validation path can safely reject nonconforming responses. JSON mode alone is not equivalent to schema validation.

Validate the response before execution

Provider responses can place the generated content in different fields. Inspect one real response in n8n before writing the parser. The following Code node assumes the model returned a JSON string in message.content; adjust the path to match the response you actually receive.

const raw = $json.choices?.[0]?.message?.content;

if (typeof raw !== 'string') {
  throw new Error('Model response did not contain message.content as a string');
}

let extracted;
try {
  extracted = JSON.parse(raw);
} catch (error) {
  throw new Error('Model returned invalid JSON');
}

const required = ['category', 'priority', 'summary', 'customer_email'];
const missing = required.filter((key) => extracted[key] === undefined || extracted[key] === '');

const validCategory = ['billing', 'technical', 'account', 'other'].includes(extracted.category);
const validPriority = ['low', 'normal', 'high', 'urgent'].includes(extracted.priority);
const validEmail = typeof extracted.customer_email === 'string' &&
  /^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/.test(extracted.customer_email);

if (missing.length || !validCategory || !validPriority || !validEmail) {
  throw new Error('Extracted object failed application validation');
}

return [{ json: { extracted } }];

For production use, replace this lightweight check with a maintained JSON Schema validator where your n8n deployment permits it. The schema in the request and the schema enforced in validation should be versioned together. Add a schema version to the output if downstream systems need to distinguish revisions.

Add human approval to the AI Agent tool

Use the validated object as context for an AI Agent. Give the Agent a narrowly defined tool, such as CreateSupportTicket, rather than broad database access. Configure human review for that selected tool in the AI Agent’s Tools Panel.

The n8n documentation states that a workflow pauses when an Agent attempts a tool requiring review. A reviewer can approve the call, allowing the tool to execute with the proposed input, or deny it, canceling the action. n8n supports several approval channels, including its built-in chat interface and integrations such as Slack, Telegram, Discord, Teams, email, WhatsApp, Google Chat, and Outlook email. See the official n8n human-in-the-loop documentation for the current setup steps and channel details.

A useful approval message should expose the proposed action and parameters:

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

The source documentation identifies $tool.name and $tool.parameters for this review context. Keep the message readable and include the original request or a ticket reference when reviewers need additional context.

Your Agent system prompt should also explain the review behavior:

The CreateSupportTicket tool requires human approval. If approval is denied, do not retry automatically. Tell the user that the action was not completed and explain what information or correction is needed.

Limitations and troubleshooting

The model returns Markdown or extra text

Check whether the endpoint supports the structured-output parameters you sent. If not, remove unsupported parameters, tighten the instruction, and keep the Code-node validation as a hard gate. Never send an unvalidated object to the write tool.

n8n cannot find the expected response field

Inspect the HTTP Request output and update the parser. OpenAI-compatible APIs can share request conventions while differing in response details and supported parameters.

The approval request is too vague

Use a narrowly scoped tool and include $tool.name plus $tool.parameters in the approval message. Do not ask a reviewer to approve an opaque instruction such as “process this request.”

A denied tool call causes a loop

Add explicit denial behavior to the Agent system prompt and configure the workflow so a denial ends the action path or routes to clarification. The n8n documentation recommends explaining which tools require approval and how the Agent should respond to rejection.

Reviewers approve incorrect data

Schema validity does not prove semantic correctness. Show the source excerpt, extracted fields, and intended action together. For high-impact workflows, require a reviewer to confirm sensitive fields independently.

Conclusion

The safest n8n pattern for structured extraction is not “let the model write directly.” Extract into a constrained object, validate it, then place human approval in front of the tool that changes the outside world. An OpenAI-compatible API can simplify model access, while n8n supplies orchestration and approval controls. With OneMux, use the documented compatible endpoint and model parameters, verify the configuration in your own environment, and treat unsupported structured-output features as a reason to stop or fall back to a separately validated response path.