Developer platform

Authentication and scopes

Keys are created in Settings, then Integrations, then API keys, and are shown once at creation. Each key carries scopes, so a key that only needs to create leads holds only leads.create and can do nothing else if it leaks.

• Header: x-api-key
• Scoped keys, for example leads.create
• Issued per workspace and rotatable
• Shown once at creation

Lead intake

POST /v1/public/leads is the entry point for anything that produces an enquiry. The lead is deduplicated against the workspace contacts by phone and email, then routed by your own routing rules, so a lead created through the API is treated exactly like a lead that arrived from a portal.

• POST /v1/public/leads
• Send at least a phone number or an email address
• Accepts requirement fields, source, utm, budget, bedrooms and language
• Returns lead_id, reference, contact_id and a duplicate flag
• Responds 201 on create and 200 when it matched an existing lead

Idempotency and rate limits

Pass an external_id and a retry is safe: when a lead with that id already exists the original is returned with duplicate set to true and a 200, rather than a second record being created. Lead intake is limited to 240 requests a minute per key or IP, and an over limit request returns 429 with a Retry-After header.

• external_id up to 120 characters makes a retry safe
• A duplicate returns the original record
• Lead intake: 240 requests per minute per key or IP
• 429 with Retry-After when over the limit

Outbound webhooks

Register an endpoint and subscribe it to the event types you want. Every delivery carries the event type, a delivery id that stays stable across retries so you can deduplicate, and a signature when the endpoint has a secret configured.

• x-clixcrm-event names the event type
• x-clixcrm-delivery is stable across retries
• x-clixcrm-signature is sha256 plus a hex HMAC SHA256 of the raw body
• Compare the signature in constant time
• Any 2xx is success, anything else is retried
• Backoff of 1s, 2s, 4s and upward, capped at 30 minutes, six attempts
• After six attempts a delivery is marked dead and is visible in the CRM

The 23 event types

Leads, contacts, listings, portals, meetings, viewings, reservations, bookings, deals, documents and messages. An endpoint subscribes only to the ones it needs.

• lead.created, lead.updated, lead.assigned, lead.stage_changed, lead.sla_breached
• contact.created
• listing.created, listing.approved, listing.published, listing.rejected
• portal.error
• meeting.created, viewing.completed
• reservation.created, reservation.expired, booking.created
• deal.created, deal.updated, deal.won, deal.lost, deal.cancelled
• document.generated, message.received

Portal feeds and media

Each portal account reads a listing feed in its own format, and the feed URL is itself the credential: the token is issued per portal account, and rotating it retires the old URL. Listing photographs are served through permanent public links that verify a signature and then redirect to a freshly signed storage URL, so a portal CDN can cache the link indefinitely without any long lived storage credential existing.

• One feed URL per portal account, in that portal format
• Token rotatable from the CRM
• Permanent public media links backed by short lived storage URLs

Zapier

Clix exposes its trigger list and a real sample record for each trigger, which is what a Zapier app reads to build its triggers and to show field names while a Zap is being written. Each trigger names an event type that an outbound webhook endpoint can subscribe to.

• Trigger list exposed to the Zapier app
• A real sample record per trigger, or null when the workspace has none yet
• Triggers map onto the outbound webhook event types

Inbound webhooks Clix receives

The other direction is already wired for the providers Clix integrates with, each with its own verification: Meta lead ads, WhatsApp Business Cloud, portal lead pushes including a Property Finder HMAC signature, e signature envelope events, Microsoft Graph mail notifications and Stripe billing events.

• Meta lead ads, with the verification handshake
• WhatsApp Business Cloud messages and delivery statuses
• Portal lead pushes, one endpoint per portal account
• E signature envelope events: sent, viewed, signed, declined
• Microsoft Graph mail notifications
• Stripe billing events

Why the public surface is deliberately narrow

The public API exposes lead intake, portal feeds, media links, Zapier support and outbound webhooks. It is not a full read and write API across every CRM resource, and that is a security decision rather than a missing feature. A key that leaks should not be able to read a brokerage client database, so privileged operations stay inside the authenticated application behind role based permissions, and the public surface is kept to the narrowest set that still lets you connect a website, an ad account and your own systems.

• Every public key is scoped to the operation it needs
• Privileged reads and writes stay inside the authenticated application
• Outbound webhooks cover most of what an integration needs to observe
• Credentials and internal endpoint detail are shared under agreement, not published

If you need more than this

Tell us the use case. Some of what people ask for already exists behind authentication and only needs a scope, some is better solved with a webhook subscription than a polling endpoint, and some genuinely is not there. We would rather have that conversation than publish a surface we cannot secure. Write to sales@clix-crm.com with what you are trying to connect.