Build an n8n webhook that returns CometAPI summaries.

Last reviewed: 2026-08-05

Direct answer

A CometAPI n8n webhook can accept a JSON document, validate its text field, send that text through an n8n language-model workflow, and return a small JSON summary. Use this logical sequence: Webhook -> validation and normalization -> agent or chain with OpenAI Chat Model -> Respond to Webhook.

The implementation rests on four documented contracts. The CometAPI n8n integration guide explains how to create an OpenAI-compatible credential with a CometAPI key and the documented /v1 Base URL. The n8n Webhook documentation covers POST triggers, separate test and production URLs, authentication, and response modes. The OpenAI Chat Model documentation covers model selection, temperature, output limits, timeouts, and retries. The Respond to Webhook documentation explains controlled JSON replies and an important limitation: if the workflow errors before its first response node executes, n8n returns status 500.

Build the workflow

In the n8n project, create an OpenAI API credential. Put the real CometAPI value only in the protected API Key field; use [REDACTED] in screenshots, exports, tickets, and notes. Enter the /v1 Base URL shown in the CometAPI guide, save the credential, and run its connection test.
Add a Webhook trigger. Choose POST, give it a stable path such as summarize, require header authentication, and set Respond to Using Respond to Webhook node. Use the test URL while assembling the workflow. Use the production URL only after publishing the workflow.
Define a caller-supplied correlation field. This tutorial requires request_id to be a short, non-sensitive string created by the caller. Allow only letters, numbers, hyphens, and underscores, with a local maximum of 64 characters. The value must never contain submitted content or a credential. Copy the validated value into a stable workflow field before the model call and preserve it separately from model output.
Add a validation branch before invoking the model. Require one JSON object containing a valid request_id and one nonempty string named text. Reject arrays, blank strings, and unexpected types. A local cap such as 12,000 text characters is a reasonable first cost and latency guardrail; it is an application policy, not a documented n8n platform maximum.

A valid test body looks like this:

{
  "request_id": "req-42",
  "text": "The support team resolved the queue backlog, changed the escalation owner, and scheduled a follow-up review for Friday."
}

Add an agent or basic language-model chain and attach the OpenAI Chat Model sub-node using the saved CometAPI credential. Select a model currently available to the account instead of copying an old model name from a screenshot. For the initial implementation, leave Use Responses API off so the node follows its documented default Chat Completions behavior. Enable another endpoint family only after verifying that exact CometAPI model and route.

Use a constrained prompt. Do not send request_id to the model because it is routing metadata, not source material:

Summarize the input in no more than three short bullets.
Preserve names, dates, quantities, and explicit decisions.
Do not add facts that are absent from the input.

Input:
{{ $json.body.text }}

Start with low sampling temperature, a bounded output-token setting, a finite timeout, and one retry. Those controls are documented model-node options. Treat their particular values as workload policy and measure real latency before increasing them.

Place Respond to Webhook after the successful model path. Choose JSON and map only ok, the generated summary, and the preserved caller-supplied request_id. Do not build the response from the model object alone, because doing so can lose the correlation field.

A stable success response is:

{
  "ok": true,
  "summary": "The backlog was resolved; escalation ownership changed; a follow-up is scheduled for Friday.",
  "request_id": "req-42"
}

Happy-path operator workflow

Use harmless sample text and a unique request_id against the test URL. Confirm in order that the webhook captured one item, validation accepted both fields, normalization preserved request_id, the model node used the intended credential and model, and the response node returned status 200. Confirm that the returned ID exactly matches the submitted ID and that the summary is nonempty and adds no unsupported facts.

Publish the workflow, call the production URL once with a new ID, and confirm that the execution appears in n8n’s execution history. A successful credential test proves connectivity; this end-to-end test proves field mapping, prompt behavior, correlation, response wiring, and caller-visible status handling.

Error-path operator workflow

Invalid input is a controlled error because validation happens before the model. Route a request with a valid request_id but missing or blank text to Respond to Webhook and return status 400:

{
  "ok": false,
  "error": {
    "code": "INVALID_INPUT",
    "message": "text is required"
  },
  "request_id": "req-42"
}

If request_id itself is absent or invalid, return 400 without echoing an untrusted value. The caller already knows the value it attempted to send, while operators can use the n8n execution record for investigation.

Model, credential, and timeout failures require different expectations. The refetched Respond to Webhook documentation states that an error before the first response node executes returns 500. Therefore, this baseline workflow does not promise custom 502 or 504 bodies for failures thrown by the model node. Its public runtime-error contract is status 500 with an implementation-defined body that callers must not parse.

Emit a sanitized start record after validation but before the model call. That record contains the validated request_id, so an operator can correlate a later 500 even when the response node is never reached. Then inspect the matching n8n execution, correct the credential, model, or timeout configuration, and retry only when doing so is safe. Do not advertise custom upstream status codes until the deployed n8n version has a documented, tested error-to-data route that reaches Respond to Webhook.

Before enabling the production URL, review the credential-handling guide and the client timeout guide .

Who this is for

This pattern is for teams using n8n Cloud or a self-hosted n8n instance that need a narrow HTTP interface for summarization. It fits internal support tools, content intake pipelines, ticket triage, and back-office automations where one caller submits one text document and expects one controlled response.

It is not a complete public API gateway. An internet-facing endpoint still needs caller authentication, request limits, abuse controls, retention rules, monitoring, and an owner who can disable the workflow during an incident.

Key takeaways

Keep the CometAPI value inside n8n’s credential store and redact it everywhere else.
Make request_id caller-supplied, validate it, preserve it before the model call, and never include sensitive data in it.
Use the Webhook test URL during development and the production URL only after publishing.
Validate and normalize input before invoking a model.
Begin with the model node’s default Chat Completions behavior unless another endpoint is explicitly verified.
Return deliberate JSON for success and validation errors through Respond to Webhook.
Treat model-node failures before the response node as documented 500 outcomes, not custom 502 or 504 responses.
Log identifiers, counts, timings, and outcomes, not submitted text or generated summaries.

For a related response-design discussion, see how to choose raw JSON or rendered text .

Sources checked

Connect n8n to CometAPI establishes the CometAPI credential, Base URL, and connection-test procedure.
OpenAI Chat Model documents model selection, default endpoint behavior, output controls, timeouts, retries, and first-item expression behavior in sub-nodes.
Webhook documents POST triggers, test and production URLs, authentication choices, and response modes.
Respond to Webhook documents explicit JSON responses, status codes, first-item behavior, and the 500 behavior when a workflow errors before responding.

Contract details to verify

Credential and model contract

Confirm that the saved credential uses the current Base URL shown by CometAPI and that its connection test succeeds. Then select a model currently visible to the account. Do not treat a model label captured months earlier as a permanent identifier.

The n8n model node exposes both Chat Completions and Responses behavior. This workflow begins with the documented default because the supplied CometAPI evidence demonstrates the OpenAI-compatible credential setup but does not establish every optional Responses feature. Verify a different endpoint family separately before changing the toggle.

Input, correlation, and output contract

Document these caller rules beside the workflow:

Method: POST
Body content: JSON
Required correlation field: request_id, a validated non-sensitive string
Required content field: text, containing one nonempty string
Success status: 200
Controlled validation status: 400
Unhandled workflow or model failure before the response node: 500
Success fields: ok, summary, request_id
Validation fields when the ID is valid: ok, error.code, error.message, request_id

The caller creates request_id before sending the request. The workflow validates and copies it before invoking the model, excludes it from the prompt, and maps the preserved copy into success or controlled validation responses. The start log is written before the model call. This gives operators a correlation value even if a runtime failure prevents Respond to Webhook from executing.

Keep the public response independent of the model node’s raw shape. That lets operators change a model or internal chain without silently breaking callers.

Sanitized logging contract

Write a start event after validation and a completion event only after a successful response. Suggested fields are:

{
  "event": "summary_started",
  "request_id": "req-42",
  "execution_id": "exec-42",
  "workflow_version": "3",
  "environment": "production",
  "route": "summarize",
  "outcome": "started",
  "model_id": "configured-model",
  "input_char_count": 1280
}

A completion record can add status_code, elapsed_ms, retry_count, and output_char_count. For a failed execution, record a sanitized class such as MODEL_REJECTED or UPSTREAM_TIMEOUT in restricted operational logging. Do not log the input text, summary, prompt, headers, credential values, or unfiltered upstream response. Limit access to execution data and define a retention period appropriate to the submitted material.

Failure modes

Symptom	Documented or likely cause	Operator action
The test endpoint reports that no webhook is registered	The workflow is not listening for a test event, or the caller used the production URL during development	Start test listening and confirm which URL the caller uses
The production endpoint does not run	The workflow was not published	Publish it, then repeat a harmless production smoke test
Credential testing fails	The CometAPI value or Base URL is wrong	Reopen the saved credential, compare its Base URL with the current CometAPI guide, and retest without exposing the key
A validation error lacks correlation	`request_id` was missing or rejected	Do not echo the untrusted value; use the n8n execution record and require a valid ID on the next request
A success response has the wrong or missing ID	The response mapped from model output instead of the normalized pre-model field	Preserve the validated ID before the model call and map that copy into the response
A model rejection or timeout returns `500` instead of `502` or `504`	The model node failed before Respond to Webhook executed	Treat `500` as the baseline contract and inspect the execution plus pre-model start log
The caller waits until its own timeout	The model timeout is too high or the response node is not reached	Bound the model timeout and verify that the successful path reaches one response node
The wrong record is summarized in a batch	n8n sub-node expressions resolve against the first item	Send one document per webhook call or normalize the workflow before invoking the sub-node
A second response customization has no effect	Respond to Webhook ignores a later response after the first one executes	Consolidate routing so exactly one response node executes per controlled outcome
Runtime failures expose unstable body details	The caller attempted to parse n8n’s implementation-defined `500` body	Parse only the status, correlate with the submitted ID, and inspect restricted execution data

FAQ

Can the webhook be left unauthenticated?

n8n allows multiple authentication choices, including no authentication, but a summarization endpoint should not be exposed that way. Require header authentication, restrict callers where practical, and avoid placing sensitive values in URLs or workflow exports.

Who creates request_id?

The caller creates it before sending the request. Keep it short, non-sensitive, and unique enough for the caller’s own correlation needs. The workflow validates it, copies it before the model call, excludes it from the prompt, writes it to the sanitized start log, and echoes it on success or controlled validation failure.

Will every error response include request_id?

No. Controlled validation responses can echo a valid ID. A model or workflow exception before Respond to Webhook executes returns 500, so the workflow cannot guarantee a structured body or echoed ID. The caller still has the value it sent, and the pre-model start log provides the operator-side correlation point.

Should I enable Use Responses API?

Not for the first smoke test unless the exact CometAPI model and endpoint behavior have been verified. The n8n node defaults to Chat Completions when the toggle is off. Establish a working baseline first, then test any endpoint change as a separate contract migration.

Why wrap the model output instead of returning it directly?

A wrapper gives callers stable fields and preserves the caller’s correlation ID. It also prevents accidental exposure of provider metadata. The Respond to Webhook node can return JSON with a chosen status code when the workflow reaches it.

Can Respond to Webhook return plain text?

Yes, but its documented text response defaults to HTML content. JSON is clearer for programmatic callers and avoids ambiguity about content type and escaping.

Can one call summarize several documents?

This starter contract deliberately accepts one document. The model sub-node and response node both have first-item behavior that matters in multi-item workflows. Add explicit aggregation or iteration before expanding the public contract, and test ordering and partial failures.

Reader next step

Create the saved n8n credential, build the happy path, and test it with harmless text plus a caller-generated request_id. Then verify a controlled 400 using blank text. In a staging copy, exercise one model failure and confirm that it produces the documented 500 while the sanitized start log retains the submitted correlation ID. Review the execution data and logging fields before publishing the production webhook.

Start with CometAPI and use the official n8n connection test before wiring the credential into the summarization workflow.