Build an AI Workflow with CometAPI and Activepieces

Last reviewed: 2026-09-02

Direct answer

Use Activepieces’ native CometAPI piece for the first version of this workflow. The CometAPI Activepieces integration guide says to create a flow from scratch, add the Ask CometAPI step, attach a CometAPI credential, select a current model, provide a prompt, and click Test. Activepieces also lists Ask CometAPI as an integration action that sends a prompt to any model supported by CometAPI on its CometAPI integration page .

A useful first workflow is a small, observable text transformation. An upstream event can provide a support note, and Ask CometAPI can return a concise internal summary for a later review or routing step. Begin with a fixed, harmless fixture so you can distinguish configuration errors from input mapping problems. Keep the credential in the Activepieces connection field, never in the prompt, a mapped text value, a source file, or a run log.

1. Open an Activepieces project and choose Create Flow, then From Scratch. On the canvas, click the plus button, search for CometAPI, and choose Ask CometAPI.
2. Select the stored CometAPI credential. Choose a model from the model control instead of copying an old screenshot or relying on a model that may no longer be offered. Enter a short prompt, and add a system message only when the task needs a stable behavior boundary.
3. Leave optional sampling controls at their defaults for the first test. If you change them, record the values with the run so another operator can reproduce the result. Map only the input fields the prompt needs.
4. Click Test. On the happy path, the step returns text and also identifies the model and usage counts. Save the test result as a functional check, but redact user content and credentials before sharing it.
5. Connect the response to the next flow step only after the isolated test succeeds. Run one controlled sample, confirm that the downstream field receives the intended text, and then expand the input mapping gradually.

The public Ask CometAPI action source makes the boundary explicit. The action constructs a single-turn chat completion with an optional system message and one user prompt. It sends the request through the CometAPI chat-completions path and returns response text, a model identifier, and usage data. That contract tells you what the next Activepieces step can safely consume.

If the test fails, stop the downstream run and classify the error before trying again. Check the credential and available account balance for an authentication or billing problem. Check the selected model and required prompt for a request or model problem. For a rate-limit or server response, wait and retry deliberately. Do not create an automatic retry loop until you understand the action’s cost and side effects: the public implementation describes each generation as a fresh, non-idempotent call that consumes tokens.

Who this is for

This tutorial is for developers, operations-minded automation builders, and small teams that want a low-code CometAPI integration without writing a dedicated service. It assumes you can sign in to an Activepieces project and manage a CometAPI account credential, but it does not assume TypeScript, Python, or a separately hosted API client.

Activepieces describes itself as an AI automation platform in its documentation overview . The overview models a flow as a trigger followed by selected steps and describes both cloud and self-hosted operation. That makes the native piece useful when the surrounding work already lives in an Activepieces flow: the AI call remains a visible step with an editable prompt, while the credential is supplied through the connection field.

Use this pattern when a single prompt should transform one event at a time, such as summarizing a note, classifying a short message, drafting a reply for review, or extracting a small set of labels. It is not a replacement for a multi-turn agent, a durable conversation store, or a workflow that requires a strict schema the action does not promise. If you need another CometAPI endpoint, the piece page exposes a Custom API Call action; review that endpoint’s contract separately instead of assuming Ask CometAPI supports it.

Key takeaways

• The native Ask CometAPI action is the starting point: create a flow, add the step, attach a credential, choose a current model, write a prompt, and test it.
• Treat the model selector as runtime configuration. Keep the model ID in a flow variable or documented setting when you expect to change models, and verify it before a release.
• The action is single-turn. It accepts one prompt and an optional system message; it does not provide multi-turn history by itself.
• The public implementation validates temperature from 0 through 2, top-p from 0 through 1, and a positive maximum-token value. Use conservative values until you have a reason to tune them.
• Capture a run ID, step name, selected model, status, latency, response length, and usage counts. Never capture the API key, a full authorization value, or unredacted user text in routine logs.
• A successful test is not proof that every future model or input will work. Keep a small regression prompt and rerun it after changing the credential, model, prompt template, or deployment.

For tutorial maintainers, the model catalog prepublish checklist is a useful companion when a model ID changes. For payload review, use the request-body fixture review before promoting a mapped prompt.

Sources checked

The primary setup evidence is the CometAPI guide for Activepieces , which documents the prerequisites and the setup sequence: create a flow, add Ask CometAPI, enter the API key in the field, choose a current model, provide a prompt, and test the step. It also says to verify the key and available balance when a test fails.

The Activepieces CometAPI integration page confirms the native action name and its visible fields: Model, Prompt, System Message, Temperature, Max Tokens, and Top P. It also lists a Custom API Call option, so this article keeps that option separate from the simple Ask CometAPI path.

The Activepieces action implementation is the contract-level source for the single-turn message shape, optional parameter validation, chat-completions request path, returned usage object, and status-specific errors. Reading the implementation prevents the tutorial from implying that the step maintains conversation history or silently retries a generation.

Finally, the Activepieces documentation overview supplies platform context. It explains flows as a trigger followed by selected steps and presents cloud and self-hosted options. These public sources were checked together so the UI instructions, action behavior, and platform context agree.

Contract details to verify

Before a real run, verify each item against the current UI and the model catalog available to your account:

Keep a tiny fixture that does not contain customer data. One example is:

Input: Return exactly one sentence describing a scheduled maintenance notice.
Expected shape: one short text response, a model identifier, and usage counts.

This fixture tests wiring and response extraction, not answer quality. If quality evaluation is needed, add a separate review step rather than hiding evaluation assumptions inside the CometAPI prompt. When an upstream field is mapped into the prompt, test both a populated value and an empty value; a design-time preview can look complete even when a runtime mapping resolves to nothing.

Failure modes

Authentication failure (401). The action maps this response to an authentication error. Reopen the Activepieces credential selector, confirm that the intended connection is attached to the step, and check the key in the CometAPI dashboard without copying it into chat or logs. If a screenshot must show the credential field, replace its value with [REDACTED]. After a credential rotation, rerun the isolated fixture before reconnecting downstream steps.

Rate limit (429). The implementation reports a rate-limit error. Stop repeated manual tests, note the time and flow run ID, and retry once the service allows it. Avoid parallel just-in-case runs: each successful generation is a new call and can consume tokens.

Bad request (400). The action surfaces the service’s parameter message. Check that the prompt is nonempty, the selected model is valid, and optional numeric controls remain in their documented ranges. Inspect resolved mappings rather than only the design-time preview; an empty upstream value can make a visually complete step invalid.

Model not found (404). Choose a current model from the Activepieces model control and rerun the fixture. Do not silently substitute a different model in production, because output quality, cost, and behavior can change. Record the replacement in the flow’s change note.

Server-side failure (5xx). The action reports a server error. Preserve the sanitized event, wait, and perform one controlled retry. If the second attempt fails, pause the flow and escalate with the timestamp, status, model label, and run ID, not the credential or full user payload.

Empty response. The implementation rejects a result without response content. Check the selected model, prompt mapping, and the run’s protected result view. If the service returned metadata but no text, treat that as a contract anomaly rather than passing an empty value downstream.

Unexpected downstream shape. Ask CometAPI returns an object containing text, model, and usage, while a later step may expect a plain string. Map the response text explicitly. The CometAPI key boundary guide is a useful reminder to keep credentials outside mapped content and repositories.

For routine telemetry, prefer a record like this:

flow_run_id=[RUN_ID]
step_name=Ask CometAPI
model=[CURRENT_MODEL_ID]
status=success
latency_ms=[MEASURED]
response_chars=[MEASURED]
prompt_tokens=[MEASURED]
completion_tokens=[MEASURED]
total_tokens=[MEASURED]
error_code=none

Replace the placeholders with measured values in your logging layer. Keep prompts, completions, credential fields, and authorization material out of this routine record unless your own data-governance review explicitly permits a separately protected store. For an error record, retain the status code and a short redacted reason, but do not duplicate the full request body.

FAQ

Do I need a custom HTTP request to start? No. The CometAPI guide and Activepieces integration page both document a native Ask CometAPI action. Use Custom API Call only when you have a separate endpoint contract to implement.

Can the action remember earlier messages? Not by itself. The public implementation creates a single-turn request with an optional system message and one user prompt. If conversation context matters, assemble and govern that context in earlier flow steps, then verify the resulting prompt size and data handling.

Which model ID should I enter? Use a current model exposed by the Activepieces control and available to your CometAPI account. The evidence does not justify pinning one universal ID in this tutorial, so keep the choice explicit and retest after a model change.

Should I tune temperature and top-p together? Start with defaults. If you tune either control, stay inside the ranges enforced by the action and change one variable at a time so a later operator can explain the result.

Is a test run free of side effects? A test still invokes a generation. The implementation marks the action non-idempotent and reports usage, so use a short fixture and avoid duplicate automated retries until you have a cost and replay policy.

What should I send to support? Send the flow run ID, UTC timestamp, status code, selected model label, and a redacted description of the input. Never send the API key, a full authorization value, or sensitive customer text.

Reader next step

Create a private Activepieces flow from scratch and add Ask CometAPI. Attach the stored credential, select a current model, and run the one-sentence fixture above. Confirm that the result contains text and usage metadata, then save the sanitized telemetry record. Only after that check passes should you map a real upstream field or add a downstream action.

When the controlled run is stable, review the model choice and request fixture with the linked checklists, document the chosen prompt boundary, and define what your operator should do for 401, 429, 400, 404, 5xx, and empty-response outcomes. That small runbook turns a promising CometAPI Activepieces integration into a workflow another person can operate safely.