Both n8n and Dify let you point their OpenAI integration at a custom base URL, which means DeepSeek, GLM, Kimi and Qwen work in either platform without writing code. This guide covers the exact configuration for each, three workflows worth building, the cost arithmetic that makes automation viable at volume, and the failure modes that bite once a workflow runs unattended.
Low-code platforms wrap the OpenAI API rather than reimplementing it. Their “OpenAI” node is an HTTP client with a form in front of it, and both n8n and Dify expose the base URL as a field. Point that field somewhere else and every model behind that endpoint becomes available to every node, template and workflow the platform ships.
The practical consequence: you are not waiting for either project to add DeepSeek support. It is already there, spelled “OpenAI, with a different URL”.
In n8n, model access is a credential, and the credential is where the base URL lives.
API Key: sk-YOUR_KEY
Base URL: https://aiwave.live/v1Create the key in the console — email or GitHub signup, no Chinese phone number. Every n8n node that accepts an OpenAI credential now reaches the full model catalogue.
In the node itself, the model is usually a dropdown populated from /v1/models. If your
n8n version presents a free-text field instead, enter the ID exactly:
deepseek-v4-flash
deepseek-v4-pro
glm-5
qwen3-coder-480b-a35b-instructConfirm the current list rather than trusting a written one, since model IDs are versioned:
curl https://aiwave.live/v1/models \
-H "Authorization: Bearer sk-YOUR_KEY" | jq -r '.data[].id' | sortIf a node type you need does not expose a base URL field, drop to an HTTP Request node. It always works, at the cost of building the payload yourself:
Method: POST
URL: https://aiwave.live/v1/chat/completions
Headers: Authorization: Bearer sk-YOUR_KEY
Content-Type: application/json
Body (JSON):
{
"model": "deepseek-v4-flash",
"messages": [
{"role": "system", "content": "Classify the ticket. Reply with one word."},
{"role": "user", "content": "{{ $json.ticket_body }}"}
],
"temperature": 0
}Read the result from {{ $json.choices[0].message.content }} in the next node. This
pattern is worth knowing because it also gives you access to parameters the wrapper node may not
expose.
Dify has an explicit provider type for this case. Go to Settings → Model Provider and add OpenAI-API-compatible:
Model Name: deepseek-v4-pro
Model Type: LLM
API Key: sk-YOUR_KEY
API endpoint URL: https://aiwave.live/v1
Model context size: 128000
Max token limit: 8192
Function calling: enable only if the model supports itAdd one entry per model you intend to use. Dify treats each as a separate provider row, which is tedious for ten models and useful in practice: you get an explicit list rather than a dropdown of things that may or may not work.
Two fields deserve care. Context size tells Dify how much retrieved context to pack into prompts — understate it and your RAG applications silently truncate. Function calling should only be enabled for models that genuinely support it; enabling it optimistically produces confusing agent failures rather than a clear error. Check the model directory before ticking it.
The canonical automation: classify incoming messages and route them. Cheap models are entirely adequate for classification, which is what makes this economic at volume.
Trigger: IMAP Email / Webhook
↓
OpenAI node
model: deepseek-v4-flash
system: "Classify as: billing, technical, sales, spam.
Reply with one word, lowercase."
↓
Switch node on the classification
↓
Route: billing → Stripe lookup + reply draft
technical → create issue
sales → CRM record
spam → archiveSet temperature to 0 and constrain the output format tightly. A classifier that occasionally returns “This appears to be a billing enquiry” instead of “billing” will break your switch node at 3am. Validate the output against your allowed set and route unknowns to a human queue rather than assuming the model complied.
Dify’s strength is that retrieval, prompting and a chat interface come assembled. Upload documents into a knowledge base, attach it to an application, and you have working RAG without writing a pipeline.
Two settings dominate quality and cost. Chunk size determines whether retrieved passages carry enough context to be useful. Top-k determines how many of them you pay for on every single query. Start with moderate chunks and a small top-k, then raise top-k only if answers are visibly missing information — it is the more expensive dial. The equivalent hand-built pipeline is covered in building a production RAG pipeline.
Trigger: Cron (daily 08:00)
↓
HTTP Request: fetch yesterday's records
↓
Code node: batch into one prompt
↓
OpenAI node
model: deepseek-v4-flash
system: "Summarise into five bullets. Flag anything anomalous."
↓
Slack / EmailThe batching step matters. Ten items in one prompt costs far less than ten separate calls — fewer round trips, and the system prompt is sent once instead of ten times. This is the single most effective optimisation in scheduled workflows.
Current rates for models suited to workflow automation:
| Model ID | Input / 1M tokens | Output / 1M tokens |
|---|---|---|
deepseek-v4-flash | $0.206 | $0.412 |
glm-4.7-flash | free | free |
deepseek-v4-pro | $1.09 | $2.17 |
glm-5 | $1.55 | $4.96 |
ernie-4.0-turbo-8k | $0.0012 | $0.0012 |
qwen3-32b | $0.2 | $0.6 |
Rates read from the AIWave pricing endpoint on 2026-07-26. Check live pricing before budgeting — providers revise rates.
Automation economics differ from chat economics because volume is predictable. A classification step sending roughly 500 input tokens and returning 10 output tokens, run 10,000 times a month, consumes about 5M input and 0.1M output tokens. Multiply by the rates above: (5 × input price) + (0.1 × output price). On the cheapest models that is a rounding error; on a premium model it is a real line item for work that did not need one.
This is the core argument for model choice in workflows. A classifier does not benefit from a reasoning model. Reserve capability for the steps that actually require judgement, and run the plumbing on the cheapest thing that gets the format right. Current rates are always on the pricing page.
A workflow nobody is watching fails differently from an interactive tool. Four things to build in before you enable the schedule.
Set temperature to 0, specify the exact format, and validate before the next node consumes it. A downstream node that assumes valid JSON will fail loudly on prose — or worse, silently, if it coerces.
Processing 500 records fires 500 requests as fast as your platform allows. Both platforms support batching and delay between items; use them. On the API side, retry with exponential backoff and jitter — the implementation is in rate limits.
A 503 means the provider is overloaded, not that your workflow is wrong. Add retry with
backoff, and consider a fallback model on the retry path — the request body is identical across
models, so this is a field change rather than a redesign. See error codes for
which statuses are worth retrying.
A loop bug that re-processes the same records is expensive in a way a bug in ordinary automation is
not. Cap the maximum items per run, set max_tokens on generations, and put an alert on
daily spend. Check usage per key in the console during the first week.
They compose. A common arrangement is Dify serving a chat application while n8n handles the scheduled ingestion that keeps its knowledge base current.
The difference between a demo workflow and a production one is usually output discipline. A node that returns free-form prose forces every downstream step to parse defensively; a node that returns a fixed shape lets you branch on fields.
{
"model": "deepseek-v4-flash",
"temperature": 0,
"response_format": {"type": "json_object"},
"messages": [
{"role": "system", "content":
"Return JSON only, matching exactly: {\"category\": string, \"urgency\": 1-5, \"needs_human\": boolean}. Categories: billing, technical, sales, spam."},
{"role": "user", "content": "{{ $json.body }}"}
]
}Note the constraint is stated twice — once structurally via response_format, once
in the prompt. JSON mode is an upstream model capability that varies by provider, so the prompt is your
fallback when a given model ignores the parameter. Check support on the
model directory before relying on it.
Then validate before branching. In n8n a Code node is the right place:
const allowed = ["billing", "technical", "sales", "spam"];
const raw = $json.choices[0].message.content;
let parsed;
try {
parsed = JSON.parse(raw);
} catch {
return [{ json: { category: "unknown", needs_human: true, raw } }];
}
if (!allowed.includes(parsed.category)) {
parsed.category = "unknown";
parsed.needs_human = true;
}
return [{ json: parsed }];Routing unknowns to a human queue rather than guessing is the difference between a workflow that degrades gracefully and one that quietly mislabels records for a week before anyone notices.
Scheduled workflows usually process collections, and the naive shape — one API call per item — is both slower and more expensive than it needs to be. The system prompt alone is resent on every call.
// n8n Code node: fold 20 items into one request
const items = $input.all().map((i, n) => `[${n}] ${i.json.text}`).join("\n\n");
return [{
json: {
prompt: `Classify each numbered item. Return a JSON array of
{"index": number, "category": string} with one entry per item.\n\n${items}`
}
}];Twenty items in one request typically costs a fraction of twenty requests, because the instructions are sent once and the per-request overhead disappears. The trade-off is that one malformed response affects the whole batch, so keep batches modest — ten to fifty items — and validate that the returned array length matches what you sent. If it does not, fall back to per-item processing for that batch rather than discarding it. The dedicated write-up is batch processing with Chinese AI models.
Dify assembles retrieval for you, which is convenient and hides the decisions that matter. Three of them are worth setting deliberately rather than accepting defaults.
Chunking. Dify offers automatic and custom segmentation. Automatic is fine for prose; for structured documentation, set a custom separator so sections stay intact. A table split from its header is worse than useless — it retrieves confidently and answers wrongly.
Retrieval mode. Vector search alone misses exact-match queries such as error codes and product identifiers. Hybrid search, which combines keyword and vector retrieval, handles both. If your corpus contains identifiers users will paste verbatim, hybrid is the correct default.
Top-k and score threshold. Top-k is your per-query cost dial. A score threshold lets the application return nothing rather than pad the prompt with weak matches — and a knowledge base that says “I do not have that” is far more useful than one that improvises from irrelevant context.
The most common way a document Q&A application fails is not retrieval quality; it is answering correctly from documents that are six months stale. Automate the refresh:
Trigger: Cron (nightly)
↓
HTTP Request: list documents changed since last run
↓
Loop:
HTTP Request → Dify knowledge base API
- delete the previous version of the document
- upload the new one
↓
Slack: report count of documents updatedDelete before re-uploading. Adding a revised document without removing its predecessor leaves both in the index, and retrieval will cheerfully surface the old one — a failure mode that is hard to spot because the answer looks plausible and cites a real document.
Both platforms offer agent constructs where the model chooses tools rather than following a fixed graph. They are genuinely useful for open-ended tasks and genuinely risky unattended.
For a fixed sequence of steps, a deterministic workflow beats an agent on cost, latency and debuggability. Reach for an agent when the sequence genuinely cannot be known in advance.
n8n and Dify both self-host with Docker, which changes the privacy calculus meaningfully: your workflow definitions, credentials and — for Dify — your document corpus stay on infrastructure you control. The model API remains an external call, but everything around it does not.
Two operational notes. Store API keys in the platform’s credential store rather than embedding them in workflow JSON, since workflow definitions get exported and shared. And back up the database: in Dify, the knowledge base embeddings represent real processing time, and rebuilding them from source documents is slow.
Yes. Create an OpenAI credential with your key and set the base URL to an OpenAI-compatible endpoint. Every node accepting that credential can then use DeepSeek and the other models behind it.
Settings → Model Provider → OpenAI-API-compatible. Enter the model name, API key and endpoint URL, and set the context size honestly so retrieval is not silently truncated.
The cheapest one that reliably returns the right format. Classification does not benefit from a reasoning model, and at automation volumes the price difference compounds quickly.
No. Sign up with email or GitHub and pay in USD. See accessing Chinese AI models without a Chinese phone number.
Every claim above traces back to one of these. Pricing figures come from the AIWave pricing endpoint on 2026-07-26; capability claims come from the vendors’ own documentation.