Build Klipy workflows in Make

What Make.com does with Klipy

Make.com (formerly Integromat) is a visual, no-code scenario builder that connects apps through triggers and actions. Klipy doesn't have a published app in Make's app directory: there's no drag-in "Klipy" module with pre-mapped fields to search for. If you landed on this page searching make crm expecting a walkthrough for building a CRM inside Make, this page runs the other direction. It's about wiring Make to the Klipy account you already have.

The gap is real, but it's a workable one. What closes it is Klipy's own open surface, the REST API v2 plus Svix-delivered outbound webhooks, reached through two general-purpose Make modules built for exactly this situation: HTTP (call any REST endpoint) and Webhooks (receive any webhook as a scenario trigger). Between the two, every resource Klipy exposes over the API and every event it fires over webhooks is reachable from a Make scenario. A make.com integration with Klipy today looks like two configured modules, not a bundled connector.

This isn't a replacement pitch. Make.com is a scenario builder, not a CRM, so there's nothing here to weigh against a compare page, and none exists for this pairing. If you already run Make instead of Zapier, the setup below works the same way; only the module names differ.

How it connects

Two self-build routes. Neither involves an account-linking or OAuth step inside Make itself: authentication lives on Klipy's side (an API key) or is just a URL you paste in (a webhook).

HTTP module. Create a Klipy API key under Settings, then API, then add an HTTP > Make a request module to any scenario. Set the URL to a Klipy REST API v2 endpoint, base https://api.klipy.ai/api/v2, choose API Key as the authentication type, and store your klipy_live_* key as a Make keychain credential rather than pasting it into the URL or headers. It's the same make.com API pattern Make recommends for any service without a published app. From there the module reaches contacts, companies, deals, pipelines, tasks, notes, and segments, several of which support batch-creating multiple records in a single call. Here's the actual call an HTTP module makes to create a contact:

curl https://api.klipy.ai/api/v2/contacts \
  -X POST \
  -H "X-Klipy-Api-Key: <key>" \
  -H "Idempotency-Key: 8f14e45f-ceea-4b0a-9127-1e2e3c3c1a1a" \
  -H "Content-Type: application/json" \
  -d '{"email": "person@example.com"}'

Source: Klipy API v2 introduction. The Idempotency-Key header means a retried Make execution returns the cached response instead of creating a second record.

Webhooks module. Add a Webhooks > Custom webhook trigger module in Make, copy the URL it generates, and paste it into Klipy's console, under Settings, then Webhooks. From there, Klipy delivers events to that URL as they happen, signed by Svix, so a scenario starts as soon as something changes in Klipy instead of polling for it. This is what most people mean by make.com webhooks: a trigger module fed by an external event source. 9 Klipy event types are wired today, including lead.captured, deal.moved, interaction.captured, and six more (full list: webhook event types). Here's what a lead.captured event actually looks like on the wire:

{
  "type": "lead.captured",
  "object": "event",
  "data": {
    "id": "h7w8y2f1",
    "first_name": "Jordan",
    "last_name": "Patel",
    "email": "jordan.patel@acmeanalytics.com",
    "title": "Head of Growth",
    "company_name": "Acme Analytics",
    "company_domain": "acmeanalytics.com",
    "industry": "SaaS",
    "employee_count": 350,
    "estimated_revenue": 1200000,
    "city": "Austin",
    "state": "TX",
    "country": "US",
    "linkedin": "https://linkedin.com/jordan-patel"
  }
}

Source: lead.captured webhook. One operational limit to design around: Klipy's REST API caps requests at 200 per minute per key and 1000 per minute per organization, so a high-volume scenario needs batching or throttling on the Make side, not just a faster schedule.