Last reviewed: August 31, 2026.

Direct answer

A practical CometAPI Make integration uses a custom webhook as the trigger, CometAPI’s native Make module for classification, a Router for category branches, filters for exact label matching, and a fallback route for anything uncertain. Put a Webhook response at the end of every terminal route so downstream failures remain visible.

The refetched CometAPI Make integration guide documents the native module, its saved connection, the POST method, the /v1/chat/completions path, the JSON request body, current-model selection, and the Run once check. Make’s webhook documentation explains that a custom webhook provides a URL for incoming data and normally triggers the scenario immediately.

A useful scenario shape is:

Custom webhook
  -> validate required input
  -> CometAPI: Make an API Call
  -> normalize the returned label
  -> Router
      -> billing filter -> billing destination -> Webhook response
      -> technical filter -> technical destination -> Webhook response
      -> account filter -> account destination -> Webhook response
      -> fallback -> manual-review destination -> Webhook response

Build the happy path in this order:

  1. Define a small webhook contract. Require an event identifier, subject, message, and submission time. Do not accept passwords, payment-card data, access codes, connection values, or other secrets. A sanitized fixture can look like this:
{
  "event_id": "evt-1042",
  "subject": "Cannot update billing address",
  "message": "The form rejects my postal code.",
  "submitted_at": "2026-08-31T12:00:00Z"
}

  1. Create the custom webhook and capture one fixture. Add Make’s Custom webhook trigger, click Run once, and send the fixture from a non-production client. Confirm that event_id, subject, message, and submitted_at appear as separate mapped values. Make’s documentation says parsed webhook items combine request query parameters and the body, so send application data in a JSON body and avoid putting sensitive material in a query string.

  2. Add the CometAPI module. Search for CometAPI, choose Make an API Call, and create the connection in Make’s connection dialog. Enter the real connection value only there; never paste it into a mapped field, prompt, log, screenshot, or example. Configure the documented path and method, then insert the webhook fields with Make’s mapper:

{
  "model": "your-model-id",
  "messages": [
    {
      "role": "system",
      "content": "Classify support requests. Return exactly one lowercase label: billing, technical, account, or other. Do not add punctuation or explanation."
    },
    {
      "role": "user",
      "content": "Subject: {{subject}}\nMessage: {{message}}"
    }
  ],
  "stream": false
}

Replace your-model-id with a current model ID. The documented module configuration uses /v1/chat/completions, POST, and stream: false. Keep that first request minimal until the scenario works.

  1. Inspect the actual successful output. Run the scenario before adding routes. The CometAPI guide says a successful AI response appears in the module output, but the refetched evidence does not establish a permanent Make mapper path for the returned text. Map the field shown by your own successful run instead of copying an assumed response path. Trim surrounding whitespace and normalize case in a separate mapping step, then verify that the resulting value is exactly one allowed label.

  2. Add the Router and fallback. Create routes for billing, technical, and account, plus a fallback route that sends the item to manual review. Make’s Router guide states that routes are processed sequentially and that a fallback route handles data that does not fit the other routes. Put the fallback last.

  3. Attach mutually exclusive filters. Set each named route to an exact equality check against its lowercase label. Make’s filtering guide explains that a bundle proceeds only when its conditions pass; otherwise processing on that connection terminates. Exact, non-overlapping labels reduce the risk that one request creates multiple downstream records.

  4. Finish each route deliberately. Map only the fields the destination needs: the original event identifier, the chosen category, and the support text required by the human team. The fallback should clearly mark the item as needing review rather than silently dropping it. Treat the model label as a triage suggestion, not authorization for refunds, account changes, access decisions, or case closure.

  5. Place the response last and run a happy-path check. Make warns that putting a Webhook response in the middle of a scenario can conceal a later error from normal failure notification. Put it after the destination action on every terminal route. Send one fixture for each expected category and one ambiguous fixture. For each run, confirm the parsed input, CometAPI module success, normalized label, one intended route, downstream receipt, and configured webhook response.

Who this is for

This workflow is for Make users, support-operations builders, and integration developers who want low-code classification without making the model the final decision-maker. It assumes you can create a Make scenario, connect an app module, map webhook fields, and configure a destination such as an existing ticket queue or notification channel.

It is not a substitute for a support policy engine. If a request affects money, identity, account access, legal rights, safety, or data deletion, route it to a qualified person or a deterministic approval system.

Key takeaways

  • Use a custom webhook for a narrow, documented input schema.
  • Configure CometAPI through Make’s saved connection and documented Chat Completions path.
  • Ask for one small, enumerable label rather than prose.
  • Verify the real module output before mapping a response field.
  • Use exact filters and a final fallback route; never discard an unknown label.
  • Put Webhook response modules after downstream work so failures remain observable.
  • Keep support text and connection data out of operational logs.
  • Test happy, fallback, validation, provider, and destination failures before enabling live traffic.

Sources checked

  • Connect Make to CometAPI documents the CometAPI module, saved connection, request method and path, sample request body, model selection, and Run once verification. The refetched page reports a July 2, 2026 modification date.
  • Webhooks documents custom and instant webhooks, request queues, parallel versus ordered processing, response placement, queue-full and rate-limit responses, and webhook log contents. The refetched page reports an August 28, 2026 update.
  • Router documents route branches, route order, sequential processing, conditions, and fallback routes. The refetched page reports a May 13, 2026 update.
  • Filtering documents filter placement, operands, operators, and the rule that only matching bundles continue. The refetched page reports a January 15, 2026 update.
  • Error handling points operators to Make’s error, warning, handler, exponential-backoff, and common-failure guidance. The refetched page reports a May 26, 2026 update.

Contract details to verify

Treat the scenario as several contracts joined together, and verify each one before activation:

  1. Webhook input: Confirm required fields, maximum accepted sizes, character handling, and the behavior for a missing or empty message. Give invalid input an explicit rejection or manual-review path rather than relying on an unlabeled filter drop.

  2. Data boundary: Confirm which fields may be sent to the model and which must be removed first. Make’s webhook logs can expose request metadata, headers, query data, bodies, responses, and parsed items to authorized workspace users. Minimize the incoming payload before it reaches that logging surface.

  3. CometAPI request: Verify the saved connection, POST, /v1/chat/completions, model, messages, and stream: false. Do not append the operation path twice or substitute a different endpoint body. Use the model-catalog check before pinning a model in a live scenario.

  4. Classification output: Verify the actual mapped response field, allowed labels, case normalization, whitespace handling, empty-output behavior, and maximum response size. A label outside the allowlist must reach fallback.

  5. Routing: Confirm that the three named filters are exact and mutually exclusive, the fallback is last, and every terminal route has an observable result. Make processes routes sequentially, but separate instant-webhook executions are parallel by default. If two events for the same case must remain ordered, evaluate Make’s process data in order setting and its throughput effect.

  6. Acknowledgement: Decide what the caller should receive for a routed, manual-review, invalid, or failed event. Put the Webhook response after the destination action unless you have intentionally designed an asynchronous acknowledgement plus separate failure monitoring.

  7. Fixtures: Keep at least one sanitized fixture for every category, one ambiguous request, one missing-field request, and one oversized request. The request-body fixture review provides a useful follow-up for maintaining those examples.

Failure modes

The webhook never runs. An inactive or disconnected trigger, the wrong webhook destination, or a caller-side network failure can prevent execution. Make also documents that a webhook not connected to a scenario for more than five days is deactivated and returns 410 Gone. Check webhook status before changing the classifier.

The queue rejects traffic. Make documents a 400 response when the webhook queue is full and a 429 response when its rate-limit check fails. It currently documents up to 300 incoming webhook requests per ten-second interval. Monitor queue growth, control the sender’s rate, and avoid assuming every request reached the scenario merely because the caller attempted it.

Events race each other. Instant-webhook executions run in parallel by default. Two updates for the same support case can therefore finish out of order even though routes inside one execution are sequential. Use an event identifier, check destination idempotency, and enable ordered processing when business order matters more than parallel throughput.

The CometAPI call fails. A connection problem, incorrect endpoint path, unavailable model ID, malformed JSON body, or temporary upstream error can stop the module. The CometAPI guide specifically recommends checking the connection and endpoint when a call fails. Do not route a failed call as though it were an other classification; use a distinct error path.

The output does not match a label. The model may return extra punctuation, an explanation, an empty value, or an unexpected category. Normalize conservatively, compare against an allowlist, and send every non-match to fallback. Do not use fuzzy matching for high-impact routing.

Two routes accept one bundle. Overlapping conditions can produce duplicate downstream work. Exact equality against one normalized label makes the routes mutually exclusive. Also give the destination the original event identifier so it can detect a repeated write.

A downstream action fails after acknowledgement. If a Webhook response occurs before the ticket or notification module, the caller may see success while the destination write fails. Keep the response last on every terminal route and exercise the destination failure path before launch.

Retries create duplicate tickets. A retry after an ambiguous timeout can repeat a write that actually succeeded. Check the destination for the event identifier before resending. Retry only failures that are safe to repeat, and use Make’s error-handling guidance when selecting handlers or backoff behavior.

Logs expose support data. Keep a compact operational record and exclude the full message, subject, webhook URL, request headers, query data, connection details, and raw model response. A sanitized record can use fields like these:

{
  "received_at": "2026-08-31T12:00:00Z",
  "execution_id": "run-1042",
  "event_fingerprint": "fp-1042",
  "endpoint_family": "chat_completions",
  "model_id": "your-model-id",
  "input_bytes": 128,
  "subject_characters": 29,
  "classification": "technical",
  "route": "technical_queue",
  "attempt": 1,
  "duration_ms": 840,
  "http_status": 200,
  "outcome": "routed",
  "error_class": null,
  "error_summary": null
}

For a failure, set classification and route to null, record only a short non-sensitive error class or summary, and link the alert to the Make execution identifier rather than copying the payload.

Use this operator error-path drill:

  1. Duplicate the scenario and point it at non-production destinations.
  2. Send a fixture without message and confirm the explicit invalid-input path runs.
  3. Temporarily replace the endpoint path in the duplicate with /invalid-test-path and confirm the CometAPI module’s error handler runs. Restore /v1/chat/completions immediately afterward.
  4. Verify that the error path writes only sanitized fields, raises an operational notification, and does not create a normal support ticket.
  5. Open the matching Make execution, inspect its module status, and check webhook queue or log status when relevant. Do not copy headers, the full webhook destination, or support text into an alert.
  6. Correct the configuration, restore the documented path, and run the sanitized fixture again. Before resending any production event, check the destination for the same event identifier to prevent a duplicate.
  7. Confirm that the repaired run reaches one intended route and that the fallback still catches an unexpected label.

FAQ

Should the classifier return JSON?

Not for the first version. A single lowercase label is easier to inspect and filter. Add structured output only after you have public documentation and a tested parsing contract for the selected model and endpoint.

Are Make Router branches parallel?

No. Make’s Router documentation says routes inside one scenario execution are processed sequentially. Separate instant-webhook executions are parallel by default unless you enable ordered processing.

What happens when no filter matches?

The fallback route should create a manual-review item. That preserves the request and makes prompt drift visible instead of silently discarding the bundle.

Should the webhook acknowledge receipt immediately?

For this synchronous tutorial, respond after the destination action. If the caller cannot wait, design an explicit asynchronous contract: acknowledge queue acceptance, track processing separately, and monitor every later failure. Do not move the response earlier without that operational design.

Can the model automatically close tickets or change accounts?

The safer pattern is to use the classification only for triage. Require deterministic controls and appropriate human approval for refunds, account access, identity changes, legal requests, safety cases, or destructive actions.

How should the connection value be stored?

Enter it in Make’s connection dialog as the CometAPI guide describes. Do not place it in webhook data, module bodies, variables intended for logs, screenshots, or source-controlled scenario documentation. Review the repository key-safety guide before documenting the integration.

Reader next step

Create the workflow in a duplicate Make scenario with a non-production destination. Start with the four-field webhook fixture, configure the CometAPI module exactly as shown in the refetched integration guide , inspect one successful output, and only then add the Router and exact filters. Run fixtures for billing, technical, account, an ambiguous request, a missing field, a forced provider failure, and a downstream failure. Enable live traffic only after every unknown label reaches fallback, every failure is observable, and the operational record contains no raw support text or connection data.