Last reviewed: 2026-08-26

Direct answer

A reliable Flowise CometAPI integration starts with three nodes: ChatCometAPI, Prompt Template, and LLM Chain. Put the model and its Flowise-managed credential on ChatCometAPI, connect that node to the LLM Chain’s Language Model input, and connect Prompt Template to the chain’s Prompt input. Save the chatflow, run a short preview test, and then send the same test through Flowise’s Prediction API.

Use a deliberately small prompt for the first test:

Question: {question}
Answer clearly and concisely.

Build the baseline in this order:

  1. Add ChatCometAPI from the Chat Models group.
  2. Select a credential stored in Flowise. Do not put credential material in the prompt, model name, Base Options, request payload, or logs.
  3. Enter an exact current text-model ID rather than a display label or provider name.
  4. Add the Prompt Template and LLM Chain nodes.
  5. Connect ChatCometAPI to Language Model and Prompt Template to Prompt.
  6. Save the flow and test it with streaming disabled so the first result is easy to inspect.

The refetched documentation and implementation snapshot show a version-sensitive endpoint detail. The two setup guides describe a Base Path control, while the refetched component source sets the CometAPI endpoint internally and prevents a baseURL override. Inspect the node in the Flowise build you are actually running. If it exposes Base Path, use the CometAPI address ending in /v1/ shown in the guides. If it does not expose that field, do not invent one in Base Options; retain the built-in endpoint and prove the route with a test call.

For an API-side smoke test, send this body to POST /api/v1/prediction/:id on your Flowise instance:

{
  "question": "Reply with exactly FLOW_OK",
  "streaming": false
}

A healthy path accepts the request and returns a model response. Treat the exact marker, HTTP status, latency, and parsed response type as evidence. Do not treat a saved canvas alone as proof that the provider route works.

Who this is for

This guide is for developers and low-code builders who already have access to a Flowise workspace or self-hosted instance and want a minimal text chatflow backed by CometAPI. It is also useful for operators who need a repeatable way to distinguish canvas wiring problems from provider configuration or Prediction API problems.

The article stays intentionally narrower than a full RAG or agent workflow. It proves one text-model node, one prompt, and one chain before adding memory, tools, document stores, embeddings, or vector databases. That narrow baseline makes failures easier to classify and gives you a known-good flow to duplicate for later experiments.

You should be able to create and save Flowise nodes, select a model ID, and inspect an HTTP result. You do not need to write a custom Flowise node or expose sensitive configuration in source code.

Key takeaways

  • Flowise includes a native ChatCometAPI node for text chat workflows.
  • The smallest useful canvas connects ChatCometAPI and Prompt Template to an LLM Chain.
  • Endpoint controls vary by Flowise build, so follow the fields your installed node actually exposes.
  • Start with one exact model ID, streaming disabled, and a short deterministic test prompt.
  • Test both chat preview and the Prediction API to isolate UI, flow, and client-boundary failures.
  • Log structural metadata, status, and latency—not credentials, headers, prompts, or model output.
  • Add RAG, memory, or runtime overrides only after the three-node baseline passes.

Sources checked

  • The CometAPI Flowise integration guide documents the native node, Flowise credential selection, model ID, prompt-template and LLM-chain wiring, preview testing, RAG boundaries, and common setup failures. The refetched page says it was last modified on July 2, 2026.
  • The Flowise ChatCometAPI node guide independently confirms the node’s location under Chat Models and its credential and Additional Parameters workflow.
  • The refetched ChatCometAPI component source shows a text-chat wrapper with model, temperature, streaming, token, sampling, cache, credential, and Base Options inputs. It also shows an internal endpoint and rejection of a baseURL override. The refetched GitHub page marks that repository read-only after archival on August 13, 2026, so this is implementation evidence for that snapshot rather than a promise about every installed build.
  • The Flowise Prediction guide documents the prediction route, required question or form input, streaming, history, runtime overrides, and troubleshooting statuses for API-side tests.

Contract details to verify

Build the baseline safely

Before changing a shared or production flow, duplicate it and give the copy an obvious test-only name. Record the installed Flowise version, the ChatCometAPI node type, the chosen model ID, and whether the node exposes Base Path or only Base Options. This small inventory prevents instructions for one build from being applied blindly to another.

Attach the CometAPI credential through Flowise’s credential selector. Keep it out of exported flow JSON, screenshots, prompts, test payloads, exception messages, and logs. The native component checks for a selected credential and a nonempty model name, so confirm both before debugging the chain.

Set Model Name to one exact current text-model ID. Avoid display labels, provider prefixes not present in the catalog value, quotation marks, and trailing spaces. Leave optional sampling controls at a simple baseline. A temperature of zero or another low value can make the marker test easier to compare, but the decisive check is whether the selected model and installed node accept the request.

Next, connect the graph in two branches:

  • ChatCometAPI output to the LLM Chain’s Language Model input.
  • Prompt Template output to the LLM Chain’s Prompt input.

Save after wiring. Reopen the flow once to confirm the credential selection, model ID, and connections persisted.

Run the happy path

Use the chat preview first. Ask for FLOW_OK and confirm the run reaches the LLM Chain and produces a normal text response. Capture the start time, finish time, selected model ID, node type, and outcome. If preview fails, stop there; an external client will only add another boundary to debug.

When preview succeeds, call the Prediction API with the same question and streaming set to false. Verify all four conditions:

  1. The Flowise endpoint returns a successful HTTP status.
  2. The response can be parsed using the non-streaming client path.
  3. The output contains the requested marker without an upstream error body.
  4. A second identical request follows the same route and response type.

If preview succeeds but the Prediction request fails, investigate the Flowise-facing route, flow ID, request body, and flow access policy before changing the CometAPI node.

Exercise the error path

Test boundary validation without touching provider configuration by omitting the required question from a disposable request:

{
  "streaming": false
}

The Prediction documentation identifies malformed or incomplete requests as a 400 class failure. Record that the client surfaces a controlled validation error instead of treating the body as a successful model response.

Then test node configuration in a disposable copy of the flow. Replace the model ID with invalid-model-for-path-test, save, and run the original marker prompt. Confirm that the execution is classified as a model-configuration failure, that no sensitive request data is logged, and that the client does not retry indefinitely. Restore the valid model ID and require the happy path to pass again before deleting the test copy.

Keep logs useful and sanitized

A compact event record can support both paths without storing content:

[
  {
    "timestamp": "2026-08-26T00:00:00Z",
    "event": "flowise_prediction",
    "flow_id": "flow-demo",
    "node_type": "ChatCometAPI",
    "model_id": "chosen-text-model",
    "prompt_revision": "p1",
    "streaming": false,
    "http_status": 200,
    "latency_ms": 842,
    "outcome": "success",
    "error_class": null,
    "request_id": "req-1042",
    "response_body_logged": false
  },
  {
    "timestamp": "2026-08-26T00:02:00Z",
    "event": "flowise_prediction",
    "flow_id": "flow-demo",
    "node_type": "ChatCometAPI",
    "model_id": "invalid-model-for-path-test",
    "prompt_revision": "p1",
    "streaming": false,
    "http_status": 400,
    "latency_ms": 311,
    "outcome": "error",
    "error_class": "model_configuration",
    "request_id": "req-1043",
    "response_body_logged": false
  }
]

Useful fields include timestamp, flow ID, node type, model ID, prompt revision, streaming mode, status, latency, outcome, a coarse error class, and a nonsecret request correlation ID. Exclude request headers, credential values, raw prompts, uploaded files, complete error bodies, and generated text. If a support case requires content, reproduce it with a synthetic prompt in an isolated flow.

Failure modes

ChatCometAPI is missing. The installed build may predate the node, or an administrator may have disabled or removed it. Confirm the build and available components before replacing it with an unrelated chat node.

The endpoint setting does not match the build. The setup guides describe Base Path, while the refetched source snapshot uses a built-in endpoint and blocks baseURL in Base Options. Use the control your installed node exposes. Do not add similarly named properties by guesswork.

The credential is not attached. A credential may exist in Flowise without being selected on this node, or a duplicated flow may retain an obsolete selection. Reopen the node and verify the selected credential through the UI without printing its value.

The model ID is invalid. Display names, extra spaces, provider labels, or retired IDs can fail even when the credential and endpoint are correct. Replace the field with an exact current text-model ID and rerun the smallest prompt.

Base Options contains invalid JSON. The implementation snapshot parses this field and raises an error for malformed JSON. Remove optional configuration until the baseline passes, then add one supported option at a time.

The client expects JSON while streaming is enabled. Flowise supports streaming and non-streaming prediction modes, but clients handle them differently. Keep streaming off for the first test. Enable it only after the non-streaming contract is recorded and the client has a stream parser.

The Prediction boundary returns 401, 404, 413, or 500. The Flowise guide associates these with flow access, an incorrect or missing flow ID, an oversized payload, or node/server misconfiguration. Classify the boundary failure before editing the provider node.

The flow attempts an image task. The refetched CometAPI guide scopes ChatCometAPI to text chat, chains, agents, and RAG answer generation. Use a workflow designed for image operations rather than forcing an image request through this chat node.

Requests time out or encounter rate limits. Keep the initial prompt small and concurrency low. For a RAG extension, reduce retrieved context before changing several controls simultaneously. Restore the known-good three-node test to determine whether the issue follows the larger flow.

FAQ

Do I need a custom HTTP node?

Not for this baseline. Both setup guides identify a native ChatCometAPI node, and the component snapshot shows it as a Chat Models integration wrapping a chat endpoint.

Should every Flowise build have a Base Path field?

No. The refetched evidence shows differing interfaces. Follow the installed node: populate Base Path only when that field exists and is documented for the build; otherwise retain the built-in endpoint and verify it with a request.

Can I change models without rebuilding the canvas?

Yes. Keep the node, credential selection, prompt, and chain wiring stable, change only the exact model ID, save, and repeat the marker test. Duplicate an important flow before testing model changes.

Can an application call the finished chatflow?

Yes. Flowise documents POST /api/v1/prediction/:id as the primary interaction route. Begin with a question and non-streaming response. Add history, files, variables, or overrides only when the basic request is stable. Runtime overrides are disabled by default for security according to the refetched Prediction guide, so do not assume a client can alter node settings.

Can this become a RAG flow?

Yes, but ChatCometAPI remains the answer-generating chat model. The refetched CometAPI guide says document processing still needs a compatible embeddings provider and vector store. Prove document retrieval separately before connecting it to a conversational retrieval chain.

What should I retain after a successful test?

Keep the flow revision, model ID, node type, prompt revision, streaming mode, timestamps, status, latency, and outcome. Do not retain credentials, headers, raw user input, uploaded files, or generated content in routine diagnostic logs.

Reader next step

Create a disposable three-node chatflow and require both preview and Prediction API tests to return the marker before adding memory, tools, or retrieval. If the endpoint controls differ from a screenshot or guide, use the installed node as the immediate interface and document what you observed.

Before sharing the flow, verify the CometAPI base URL and endpoint family and check the model catalog before publishing tutorial code . Those checks reduce failures caused by copied display names or instructions from a different client version.

When you are ready to create the provider credential and run the baseline flow, Start with CometAPI .