n8n Order Automation: Classify Orders and Draft Replies With HiAPI

Every local shop owner knows the loop: a new order message lands in the inbox or a form, and someone has to read it, decide what it is, and write back. Routine orders are quick, but the minutes add up across a day, and a complaint buried in the pile can sit unanswered for hours.

This tutorial builds the whole thing as an n8n workflow: a webhook receives the order, an AI model classifies it and drafts a reply, routine orders get answered automatically, and complaints go straight to a human. The model connection runs through HiAPI, so one key covers every model used in the flow.

Workflow automation roundups in 2026 keep recommending n8n for exactly this kind of small-business job, mostly for its self-hosting option and its built-in LLM nodes (Atlassian workflow automation roundup 2026; techaigoz 2026). A recent post about wiring n8n and Claude into local shop order handling picked up roughly 51k views on X in October 2026, which suggests plenty of owners are looking for a concrete setup rather than another tool list. This is that concrete setup.

The scenario

Picture a small restaurant or retail shop. Orders arrive through a website form, a messaging app, or an email alias. Each message needs three things:

1. Intent: is this a routine order, a question, or a complaint?
2. A reply: a draft the customer can actually receive.
3. Routing: routine orders close themselves; complaints reach a person immediately.

The workflow below does all three. It is deliberately small so it can be rebuilt in an afternoon.

What you need

• A HiAPI account with an API key. Sign up, open the console, and copy the key. HiAPI is OpenAI-compatible: the endpoint is https://api.hiapi.ai and authentication is a standard Authorization: Bearer sk-... header.
• n8n, either cloud or self-hosted. If you self-host, keep it updated, because the Base URL setting used below only exists on the newer AI node system.
• A notification target for the human-escalation branch: Feishu, WeCom, email, or anything n8n can post to.

No other services are involved. No image or video models appear anywhere in this flow; it is a text-only workflow.

Step 1: Point the OpenAI Chat Model node at HiAPI

This is the core of the entire build, and it is one credential screen.

Add an OpenAI Chat Model node in n8n (the AI-node subnode, not the legacy OpenAI node). In its credential settings:

• Base URL: https://api.hiapi.ai
• API Key: your HiAPI key
• Model: deepseek-v4.1-flash

That is the full connection. Because HiAPI speaks the OpenAI chat-completions format, n8n treats it like a standard OpenAI-compatible provider, and every other node in the workflow works unchanged.

One version note: the Base URL field is only exposed in recent n8n versions. If your OpenAI Chat Model credential has no Base URL input, your n8n is too old. Upgrade first; this tutorial assumes a version where the field exists.

Step 2: Build the workflow

The flow has four parts, in order:

1. Webhook trigger – fires when a new order message arrives.
2. AI node – classifies the message and drafts a reply in one pass.
3. IF branch – routine orders go left, complaints go right.
4. Notify node – sends the outcome where it needs to go.

Trigger

Use a Webhook node (or an n8n form trigger if orders come from a form you control). Pass at least the customer message and an order ID into the workflow.

Classify and draft

Attach an AI Agent or basic LLM chain that calls the OpenAI Chat Model node from Step 1. Give it a system prompt that forces structured output. Here is a prompt written for this workflow; adjust the categories and tone to your shop:

You are the order assistant for a small local shop. For each incoming
customer message, do two things:

1. Classify it into exactly one category:
   - order: the customer is placing or confirming a routine order
   - question: the customer asks about products, hours, delivery, or stock
   - complaint: the customer is unhappy or reporting a problem

2. Draft a short reply (under 80 words) in the same language as the
   message. For orders, confirm the order and state the next step. For
   questions, answer using only the shop facts in the context below.
   For complaints, apologize briefly and say a team member will follow
   up personally; do not attempt to resolve it yourself.

Output exactly this format on two lines:
CATEGORY: <order | question | complaint>
REPLY: <the drafted reply>

Shop facts:
- Opening hours: 10:00-21:00 daily
- Delivery: same day within 5 km, otherwise next day
- Payment: cash or card on delivery

If the message is ambiguous between order and question, choose question.
Never invent products, prices, or policies that are not listed above.

The strict output format matters: the IF branch downstream keys off the CATEGORY: line, so keep that contract stable.

Branch on intent

Add an IF node that checks whether the category is complaint:

• Not a complaint (order or question): send the drafted reply through your messaging or email node. This is the auto-reply path.
• Complaint: skip the auto-reply entirely and fire the notification node to a human channel with the original message, the category, and the AI's draft attached as context. A person decides the actual response.

The auto-reply path is worth a moment of care. Fully automatic replies are fine for routine orders, but anything emotional or ambiguous should default to a human. The IF branch is what makes that policy real instead of aspirational.

Notify

End both branches with a notification: the customer-facing send on one side, an internal alert on the other. If you run Feishu or WeCom, n8n has nodes for both; plain email works too.

Step 3: Control the cost by routing on task

One model is enough to run this workflow end to end, but two models run it cheaper. As of Oct 2026, HiAPI prices:

Routine order messages are short and templated, which is exactly what a fast, inexpensive model handles well. Complaints carry more nuance and often more context, which justifies the stronger model for that slice of traffic.

The practical pattern: run the whole workflow on deepseek-v4.1-flash, and for anything the IF branch flags as sensitive or that arrives with a long thread attached, route that call to claude-opus-4-8 with a second OpenAI Chat Model credential. Same Base URL, same key, different model name. See the deepseek-v4.1-flash model page and the claude-opus-4-8 model page for current specs and pricing.

If you want the reasoning behind routing by task in the first place, we covered it in depth when Notion shipped automatic model routing earlier this month: the short version is that no single model wins on both cost and quality, so the scheduler (here, your IF branch) should pick per task. Read why routing by task beats picking one model for the full argument.

FAQ

Is it safe to store my HiAPI key in n8n?

Yes, as long as the key lives in n8n's credential store rather than in workflow nodes or environment files you pass around. n8n encrypts credentials at rest, and the key never appears in execution logs the way a pasted string in a node would. Rotate the key if you ever suspect exposure, and scope separate keys per workflow if your HiAPI console supports it.

What should I do when a call returns 429?

A 429 means rate limiting, usually from bursty traffic. Do not treat it as a failure: add an n8n retry with exponential backoff on the AI node, and if you run sustained volume, check your HiAPI console tier. Retrying after a short wait clears the vast majority of 429s.

Can I switch to a different model later?

Yes, and that is the point of routing by task. Duplicate the OpenAI Chat Model credential, change the model name, and point a different branch at it. No other node changes, because every model behind HiAPI uses the same OpenAI-compatible endpoint and the same key.

Why use a HiAPI key instead of official provider keys directly?

One key covers every model in this workflow and any model you add later, with a single balance and one place to check spend. With separate official keys you would hold a credential and a billing relationship per provider, and every model swap becomes key management work. An aggregator key turns it into a one-field change.

Does the workflow need streaming responses?

No. Order classification and reply drafting are short, one-shot generations where the result arrives in a few seconds. Streaming is a nice-to-have for chat UIs; a backend workflow just waits for the full response.

My OpenAI Chat Model node has no Base URL field. What now?

Your n8n version predates the field. Upgrade to a recent release; the Base URL input appears on the OpenAI Chat Model credential in the current AI node system, and this whole tutorial depends on it.

Key takeaways

• The integration is a credential change, not a coding project: Base URL https://api.hiapi.ai, HiAPI key, model deepseek-v4.1-flash.
• Classify and draft in one AI call with a strict two-line output format, then branch on the category.
• Auto-reply only routine orders; escalate complaints to a human every time.
• Spend the money where the difficulty is: flash for volume, claude-opus-4-8 for the hard messages.
• Keep the key in n8n credentials, retry on 429, and remember that swapping models is a one-field change on the same key.