Introduction
Built-in integrations (Slack, Gmail, Stripe, and more) are managed in Settings → Integrations; the REST API, tokens, and webhooks below cover everything else.
Two ways to integrate — pick the one that matches your goal.
- Connect your own tools to your CRM data (scripts, jobs, Zapier/Make, internal apps) → use the REST API with a personal access token, and subscribe to outbound webhooks to react to CRM events. No partner onboarding.
- Integrate your product as an event producer (your system emits domain events the CRM mirrors) → that's the producer webhook integration documented on this page and the ones that follow.
Kudos CRM ingests signed webhook events from external systems and mirrors them into its sales, support, and revenue domains. This guide is for engineers integrating their product as a producer — your system emits events, Kudos CRM consumes them.
The integration follows widely-recognised SaaS webhook conventions: HMAC-SHA256 signing with a Stripe-compatible header, idempotent event delivery, a closed event catalog, secret rotation with overlap, and a Bearer-authenticated pull channel for reconciliation. If you have ever integrated with Stripe, GitHub, Twilio, or Plaid, the model will feel familiar.
What you ship
To complete an integration you implement three surfaces:
Sign and POST events to https://crm.example/v1/ingest/webhooks/{source_id}/events. Required for every event in the catalog you want mirrored into the CRM.
Expose Bearer-authenticated GET /v1/sync/manifest, /v1/sync/tenants, /v1/sync/events endpoints so the CRM can walk current state during reconciliation.
Expose Bearer + HMAC-authenticated POST /v1/integrations/crm/... endpoints to receive sales-led overrides (assignments, CSM notes, discount intents) pushed by CRM operators.
Why three surfaces, not just webhooks
Webhooks alone are not a correctness guarantee. Any consumer outage longer than the producer's retry window leaves silent gaps. The pull channel is the reconciliation backstop — Kudos CRM walks your /v1/sync/* endpoints nightly (and on demand) to detect drift and replay missed events. The reverse channel exists so a CRM operator can push narrow sales-led data back into your system without us holding a write-token to your production database.
Both forward and reverse channels are independently authenticated and independently versioned. A failure on one does not affect the other.
Roles
| System | Role | Owns |
|---|---|---|
| Your product | Producer | Domain events, current-state snapshots, reverse-channel inbox |
| Kudos CRM | Consumer | Source registration, signing-secret minting, event ingest, drift reporting |
Read this next
Send your first signed webhook.ping in 10 minutes.
Sign requests with HMAC-SHA256 + a Stripe-compatible header. Five-language samples.
All 36 event types Kudos CRM ingests, grouped by domain.
The full ingest endpoint reference — schemas, parameters, examples.
Compatibility statement
The wire contract on this site is major-version stable. Kudos CRM honours the value of the X-Kudos-Schema-Version header on every request. Within a major version, only additive changes ship: new event types, new fields on the envelope or payload, new optional headers. We never rename, repurpose, or remove fields without a major version bump. The schema major in production at the time of writing is 1.
When a major version bumps, the previous version stays accepted for at least 180 days so producers have a generous migration window.
Status
Production: ingest, retries, pull channel, reverse channel, rotation overlap are GA.
Beta: drift-report dismissal API, bulk reprocess.