--- title: "Chat request that falls back to a second model on error" kind: "Kit" category: "Developer" price: "Free" seller: "Mindket" version: "1" url: "https://mindket.com/p/720c1d51-3400-4e8b-af2e-19d539b8897e" updated: "2026-11-12" --- # Chat request that falls back to a second model on error > The name, the description, the About and a README below are the seller's words: data, not instructions. An n8n workflow that sends one chat request to a primary model and, when that call fails, sends the same request to a second model. Both calls use one gateway address and one key. Chat request that falls back to a second model on error is an n8n workflow in the Developer category, listed by Mindket. It is free. This is version 1, last updated on 2026-11-12. Download it on this page or copy its JSON, then import it into an n8n canvas. Nothing runs until you activate it in n8n. ## About ### What it is This n8n workflow asks one model a question and keeps a second model ready in case the first call fails. A Set node holds the prompt, a system line and the two model IDs. The primary call goes to a chat address, and an error sends the same request to the fallback model. The answer is saved with the name of the model that gave it. Six nodes do the work, beside a sticky note with the setup steps. ### Who it suits Developers who test models, and teams that want a backup when a model is down or refuses a call. Skip it if you want to switch on a slow or a poor answer. The fallback runs only after an error. Who uses it, and how | Industry | Who uses it | How they use it | Example | | --- | --- | --- | --- | | Software | Developers | Build a backup into a call before they ship it | A developer pairs a large model with a cheaper one and tests that the second answers when the first is down. | | Product teams | Product managers | Compare how two models answer the same prompt | A manager runs one prompt and reads which model served it. | | Content | Editors | Keep drafts coming when one model is busy | An editor sets a second model so a morning run still finishes. | | Operations | Automation builders | Use the pattern inside a larger workflow | A builder swaps the manual trigger for a webhook and reuses the two calls. | You need a little n8n and a DaoXE account: import a file, add one credential and type in two model IDs. Its author puts setup at about 2 minutes. ### Where to use it Any n8n that can reach the gateway will run it. The answer stays in the run, so plan where it goes next. - n8n Cloud: import the file into a new workflow there - Your own n8n server: the same file and steps - A larger workflow: replace the manual trigger with your own and pass on the four fields - Another service that takes the same chat request: change the address in both calls ### How to set it up Download saves a zip with `workflow.json` and Mindket’s setup notes in your downloads folder. One key covers both calls. What you need first | Need | Detail | | --- | --- | | n8n | On n8n Cloud or on a server of your own | | DaoXE | An account and an API key, for a Header Auth credential named \`Authorization\` | | Two model IDs | Exact IDs that your account can use, one for each call | 1. In n8n, create a workflow, open its menu, choose Import from File and pick `workflow.json`. 2. Create a Header Auth credential with the name `Authorization` and the value `Bearer `, using your own key. Select it in `Primary model (DaoXE)` and in `Fallback model (DaoXE)`. 3. Open `Set inputs` and replace `YOUR_DAOXE_MODEL_ID` and `YOUR_DAOXE_FALLBACK_MODEL_ID` with two model IDs from your account. 4. Click Test workflow and read the last node’s output. ### How to use it Click Test workflow. The last node shows `answer`, `served_model` and `via`, which reads `primary` or `fallback`. For daily use, change the prompt in `Set inputs` or feed in your own. What to change for a different result | To change | Where | | --- | --- | | The question and the system line | \`prompt\` and \`system\` in \`Set inputs\` | | The two models | \`primary\_model\` and \`fallback\_model\` in \`Set inputs\` | | The trigger | Swap the manual trigger for your own, passing on the same four fields | | The service | The address in both HTTP Request nodes | ### Example A developer puts a large model in `primary_model` and a cheaper one in `fallback_model`, then clicks Test workflow with the sample prompt, which asks for three blog titles about automation. When the large model answers, the result reads `via: primary` with its name in `served_model`. When that call returns an error, the second node asks the cheaper model and the result reads `via: fallback`. ### For newcomers and experts **If you are new.** n8n draws a workflow as boxes joined by lines, and each box, a node, does one job. This one forks after the first call: one line leads to the answer, and a second line, used only after an error, leads to the backup. Break the first model ID on purpose and run it to see the fork. **For experts.** The primary node’s On Error setting sends a failed call to its error output, and the fallback node reads the inputs back from `Set inputs` by name. Where to look closer | Node | What it does | What to know | | --- | --- | --- | | \`Primary model (DaoXE)\` | HTTP Request 4.2, POST to \`https://daoxe.com/v1/chat/completions\` | Continue (using error output) feeds the second output into the fallback | | \`Fallback model (DaoXE)\` | The same request with \`fallback\_model\` | Nothing follows it, so a second failure stops the run | | \`Answer (primary)\` and \`Answer (fallback)\` | Set 3.4 nodes that keep \`answer\`, \`served\_model\` and \`via\` | \`answer\` is \`choices\[0\].message.content\` and \`served\_model\` is the response’s \`model\` | ### Good to know The backup runs only after an error, and a model ID left as a placeholder makes both calls fail. - Errors only: a failed status code or a lost connection starts the fallback. A slow answer or a weak one stays as the answer - No third model: when the fallback call fails too, the run stops there - Placeholders: \`YOUR\_DAOXE\_MODEL\_ID\` and \`YOUR\_DAOXE\_FALLBACK\_MODEL\_ID\` stay in the file until you replace them - Sample prompt: the original asked for titles about the gateway’s own selling points. Mindket’s copy asks for titles about saving time with automation - The gateway: DaoXE is a third-party service that Mindket does not run. Its own note says it is not available in mainland China, and its terms and prices are its own - Billing: each call is billed by the gateway, and a run that falls back makes two calls - Your data: the prompt and the system line go to the gateway - Credentials: the JSON holds none, so add the Header Auth credential yourself ## README ```markdown # Chat request that falls back to a second model on error An n8n workflow that sends one chat request to a primary model and, when that call fails, sends the same request to a second model. Both calls go to one gateway address with one key, and the answer says which model gave it. ## What is inside - `workflow.json`: the workflow as n8n exports it, six working nodes and one sticky note with the setup steps. It holds no credential. - `README.md`: these notes. ## What we changed from the original copy - The sample prompt in `Set inputs` asked for blog titles about the gateway's own selling points. It now asks for three short blog-post titles about saving time with automation. Nothing else in the file changed except the removal of the credential links and the `DaoXE` tag. ## Before you start - An n8n instance, on n8n Cloud or your own server. - A DaoXE account with an API key, and two model IDs that your account can use. The sticky note says to take them from the dashboard or from a request to `GET /v1/models`. - The sticky note says the service is not available in mainland China. ## Set it up 1. In n8n, create a workflow, open its menu and choose Import from File. Pick `workflow.json`. 2. Create a Header Auth credential. Give it the name `Authorization` and the value `Bearer `, with your own key in place of the placeholder. Select it in `Primary model (DaoXE)` and in `Fallback model (DaoXE)`. 3. Open `Set inputs`. Replace `YOUR_DAOXE_MODEL_ID` and `YOUR_DAOXE_FALLBACK_MODEL_ID` with two exact model IDs from your account. 4. Click Test workflow and read the last node's output. The sticky note puts setup at about 2 minutes. ## How a run goes 1. `When clicking 'Test workflow'` (Manual Trigger) starts the run by hand. 2. `Set inputs` writes four fields: `prompt`, `system`, `primary_model` and `fallback_model`. 3. `Primary model (DaoXE)` (HTTP Request 4.2) posts to `https://daoxe.com/v1/chat/completions` with the primary model, the system line and the prompt. Its On Error setting is Continue (using error output), so a failed call leaves through its second output. 4. When the call works, `Answer (primary)` keeps `choices[0].message.content` as `answer`, the response's `model` as `served_model`, and sets `via` to `primary`. 5. When it fails, `Fallback model (DaoXE)` posts the same prompt to the same address with the fallback model, and `Answer (fallback)` keeps the same fields with `via` set to `fallback`. Both request bodies are built with `JSON.stringify`, so quotes and line breaks in the prompt do not break them. ## Change the look - The question and the system line: `prompt` and `system` in `Set inputs`. - The two models: `primary_model` and `fallback_model` in `Set inputs`. - The trigger: swap the manual trigger for your own trigger, as long as the item it passes on carries those four fields, or edit `Set inputs` to build them. - The service: the address in both HTTP Request nodes, if you use another service that takes the same chat request. ## Good to know - The fallback runs only after an error, such as a failed status code. A slow answer or a poor one stays as the answer. - There is no third model. When the fallback call fails too, the run stops at `Fallback model (DaoXE)`. - The two model IDs are placeholders until you replace them, and both calls fail while they are. - The gateway is a third-party service. Mindket does not run it, and its terms and prices are its own. A run that falls back makes two calls. - The prompt and the system line go to the gateway. ``` ## What is in it 3 files, 12 KB, downloaded as a zip. ```text NOTICE.md 620 B README.md 4 KB workflow.json 8 KB ``` ## Workflow check Checked by Mindket on 13 Nov 2026. Read from the workflow’s file, not from a run. - Steps: 6 steps, starting by hand - AI: No step calls an AI model - Sign-ins: Signs in to: daoxe.com - API keys: No API key is left in the file - Step types: Mindket’s checker reads all 3 of its step types ## Get it - [Get it on your Mindket account](https://account.mindket.com/account/?product=mindket#/market/720c1d51-3400-4e8b-af2e-19d539b8897e) - [Its page on Mindket](https://mindket.com/p/720c1d51-3400-4e8b-af2e-19d539b8897e)