Send CLEATUS opportunities to your CRM with webhooks

Use a CLEATUS Workflow to POST opportunity data to any HTTPS endpoint the moment a new match is found, a contract enters your pipeline, or a pursuit changes phase. This is how you feed CLEATUS opportunities into your own CRM, alert your team on hot leads, or drive any downstream system that accepts a webhook.

Who this is for

Teams that want CLEATUS to push opportunity data out to their own systems (a custom CRM, a Slack/Teams alert bot, an internal API) instead of, or alongside, working inside the CLEATUS dashboard. If you instead want a no-code path into 5,000+ apps, see the Zapier integration; webhooks are the direct option.

What you'll need

• A CLEATUS plan that includes AI Workflows.
• An HTTPS endpoint in your CRM (or middleware) that can receive a JSON POST. It must be a public HTTPS URL.
• Access to build workflows in your CLEATUS workspace (Dashboard → Workflows).

How it works

A webhook in CLEATUS is a node inside a Workflow, not a standalone API subscription. The flow is:

1. A trigger starts the workflow (for example, "New recommendation").
2. Optional condition nodes (If / Else, Filter) narrow which items proceed.
3. A Webhook node makes an outbound HTTP request to your endpoint with a JSON body.

CLEATUS is the sender; your CRM is the receiver. You provide the URL and the authentication headers.

1. Webhook API documentation

Authentication and configuration

The Webhook node authenticates to your endpoint with HTTP headers you configure. There are two kinds:

To authenticate to most CRMs, add a Secret Header such as Authorization with value Bearer <your-token>, or X-API-Key with your key. CLEATUS sends whatever headers you configure.

Endpoint specification

You supply the endpoint. CLEATUS enforces a few rules on it:

• HTTPS only. Non-HTTPS URLs are rejected.
• Public hosts only. For safety, CLEATUS resolves your hostname and blocks private/internal IP ranges and cloud metadata endpoints, and pins the resolved IP for the request (SSRF protection). Your CRM endpoint must resolve to a public IP.
• No redirects. A 3xx redirect response is treated as a failure, point the node at the final URL.

Request format and structure

Response handling

• Any non-2xx response fails the node.
• The response body (up to 100 KB) is captured. If a later node in the same workflow needs your CRM's reply (for example, a returned record id), it is available as response.status, response.ok, and response.body.

Rate limits and SLA

• No CLEATUS-imposed rate limit on outbound webhook calls.
• Failure handling is set at the workflow level, not per node. A workflow has retry-attempt and retry-delay settings and an on-failure policy (for example, notify), plus a "continue on step failure" option. Because delivery can be retried and a run fires once per triggering event, design your endpoint to be idempotent (dedupe on contractId or solicitationNumber).
• Delivery is best-effort at workflow execution time; there is no separate delivery-retry queue or contractual uptime SLA on webhook delivery.

2. Available payload fields

When you add a Webhook node in the workflow builder, it sends a default structured payload: a JSON object with the trigger data nested under a trigger key. The exact fields depend on the trigger you choose. The New recommendation trigger is the best fit for "push new matches to my CRM" because it is the only trigger that carries the match score.

Default payload for the "New recommendation" trigger

{
	"trigger": {
		"entityId": "…",
		"contractId": "…",
		"bestQualityScore": 87,
		"title": "…",
		"agencyName": "…",
		"solicitationNumber": "…",
		"naicsId": "…",
		"type": "solicitation",
		"setAside": "SDVOSBC",
		"state": "TX",
		"postedDate": "2026-07-20T00:00:00.000Z",
		"deadlineDate": "2026-08-15T00:00:00.000Z"
	}
}

Fields on other triggers

Each trigger carries its own field set. Some highlights (reference as {{ trigger.<field> }} when a custom body is configured):

• Contract added to pipeline: title, agencyName, solicitationNumber, naicsCode, responseDeadline, deadlineDate, url, plus pursuitId and score.
• Pursuit phase changed: the same core contract fields plus previousColumnTitle / newColumnTitle (the phase moved from/to) and pursuitId.
• Saved search match: title, agencyName, solicitationNumber, type, setAside, postedDate, deadlineDate, plus savedQueryName. (It does not carry naicsCode, responseDeadline, or url.)

Field availability is per trigger; a variable that a given trigger does not supply resolves to an empty string.

3. Custom fields and payload shape

What ships today

The Webhook node sends the default structured payload shown in section 2. That payload already carries the standard opportunity fields (agency, title, solicitation number, NAICS, set-aside, deadline, and the match score), so many CRMs can consume it directly by reading the nested trigger object.

What is not self-serve yet

The workflow builder's Webhook editor lets you set the URL, method, and headers, but it does not currently expose a field to author a custom request body. That means, in the self-serve UI today, you cannot:

• rename the payload keys to match your CRM's schema,
• add a custom field such as a goNoGo boolean, or
• fold in extra data (contract value, full description) from a lookup node.

If you need a custom-shaped body or custom fields, tell us the exact JSON your CRM expects and we'll help configure the webhook body for your workflow. The templating capability below is what powers that configuration.

Templating syntax (for a configured custom body)

When a custom body is configured, values are filled with {{ … }} expressions:

Unresolved variables render as an empty string. (Server environment variables are intentionally not accessible.)

Example custom body (New recommendation trigger)

Rename keys to whatever your CRM expects; a constant like goNoGo is just a literal you include:

{
	"source": "CLEATUS",
	"cleatusContractId": "{{ trigger.contractId }}",
	"title": "{{ trigger.title }}",
	"agency": "{{ trigger.agencyName }}",
	"solicitationNumber": "{{ trigger.solicitationNumber }}",
	"naicsCode": "{{ trigger.naicsId }}",
	"noticeType": "{{ trigger.type }}",
	"setAside": "{{ trigger.setAside }}",
	"placeOfPerformance": "{{ trigger.state }}",
	"postedDate": "{{ trigger.postedDate }}",
	"deadline": "{{ trigger.deadlineDate }}",
	"matchScore": "{{ trigger.bestQualityScore }}",
	"goNoGo": true
}

Every {{ trigger.* }} value above is a real field the New recommendation trigger supplies.

4. Implementation guide

Build the workflow

1. Go to Dashboard → Workflows and create a new workflow.
2. Set the trigger. For pushing new matches, pick New recommendation. Other options: Contract added to pipeline, Pursuit phase changed, Saved search match, or Schedule.
3. (Optional) Add conditions. Insert If / Else and Filter nodes between the trigger and the webhook to branch on any field, for example, only continue when the match score clears a bar, the agency matches a target list, or the set-aside qualifies you. A branch that receives no items does not fire the webhook.
4. Add a Webhook action node and configure:
   • Endpoint URL: your CRM endpoint (HTTPS).
   • Method: usually POST.
   • Headers / Secret Headers: put your Authorization: Bearer … or X-API-Key: … under Secret Headers.
5. Activate the workflow.

The node will POST the default structured payload (section 2) to your endpoint whenever the trigger fires and the item clears your conditions.

Trigger on conditions or phases

• On a phase change: use the Pursuit phase changed trigger. It fires when a pursuit moves to a different pipeline column and carries the previous/new column names, so you can push "moved to Bidding" alerts.
• On a condition: use If / Else and Filter condition nodes as in step 3.

Testing and validation

1. Point the URL at a test bin first. Use a service like webhook.site or your own staging endpoint as the URL, then run the workflow and inspect the exact JSON CLEATUS sends.
2. Run the workflow and open the run log. The Webhook node logs the method, URL, item count, and the response status it received.
3. Watch for failures. A non-2xx response fails the node. Confirm your endpoint returns a 2xx on success.
4. Swap in the real endpoint once the payload looks right, and confirm the record lands in your CRM.

Current limitations (be aware)

• No custom request body in the self-serve UI. The webhook node sends the default structured payload; renaming keys, adding custom fields (e.g. a go/no-go boolean), or reshaping the body needs CLEATUS to configure the workflow for you today.
• Contract value and full description are not available in the webhook payload (no data-lookup node is exposed in the builder to include them).
• No request signing (HMAC). Authenticate via the API key/token you set as a Secret Header.
• Match score is only on the "New recommendation" trigger (and a score on "Contract added to pipeline"). Other triggers don't carry it.
• Contract value, when it is exposed elsewhere, is an estimated range and is often empty (most notices don't publish a dollar figure pre-award).
• Failure handling is workflow-level (retry attempts/delay and an on-failure policy), not a per-node toggle. Keep your endpoint idempotent; there is no contractual delivery SLA.

Support

• Email: support@cleat.ai
• Related: Zapier integration · MCP Server