Connect

API & webhooks

Quincer AI is API-first. Everything you can do in the dashboard — take over a live chat, update a lead, read the activity log — you can do via REST. This page is the map. For request/response previews against your real workspace, open Developer APIs inside the dashboard.

Authentication

All API requests use a workspace developer key. Generate one under Dashboard → Integrations → API keys, choose scopes, and pass it as a Bearer token:

Authorization: Bearer cw_dev_<your-key>

Two kinds of credentials exist: widget keys (cw_live_) are embedded in the page script and only identify a widget to the public chat endpoint. Developer keys (cw_dev_) are scoped to an organization, carry explicit scopes like leads:read or conversations:takeover, and must stay server-side.

Base URL

https://chat.quincer.com

Conversations

Use these to let an outside AI (OpenClaw, a custom agent, or your own backend) discover, take over, reply on, and hand back live conversations. The takeover/reply/handback trio is how the OpenClaw integration works under the hood.

Leads

Tasks

Knowledge base

Personas

Sales playbook

Models

Widgets

Integrations

Connect/disconnect flows still require an interactive OAuth roundtrip and live under the dashboard at Dashboard → Integrations. This endpoint is read-only by design — programmatically minting OAuth grants from a dev key is a footgun.

Webhooks

Programmatic webhook subscription management. Previously dashboard-only; now a developer key with webhooks:manage can provision a subscription end-to-end.

Voice

Voice handoff (agent claim) remains seat-licensed and is initiated from the dashboard Live Conversations UI — it requires a User row with liveHandoffLicensed, not a service key, so it has no /api/v1 equivalent.

All update operations use POST on the resource path (POST /api/v1/leads/:id). PATCH on the same path stays accepted for one major version so existing integrations don’t break, but POST is the canonical method going forward.

Resource type discriminator

Every resource response carries a read-only object field naming the resource type ("lead", "conversation", "task", "message"). List responses carry object: "list" at the envelope and per-item object fields inside data[]. Use it to deserialize polymorphic payloads (e.g., webhooks, mixed-resource responses).

{
  "object": "lead",
  "id": "clx...",
  "stage": "qualified",
  "temperature": "warm"
}

Pagination

List endpoints return a data array plus a has_more boolean and a url field naming the endpoint. Use cursor pagination via starting_after=<resource_id> — the API returns the next page of items created before that cursor. limit is bounded at 200 (default 50).

GET /api/v1/leads?limit=20&starting_after=clx_abc123

{
  "object": "list",
  "data": [ { "object": "lead", "id": "clx_xyz789", ... }, ... ],
  "has_more": true,
  "url": "/api/v1/leads",

  // Legacy fields surfaced alongside the new envelope for one major
  // version. New consumers should read `data` + `has_more`.
  "leads":  [ /* same items as data[] */ ],
  "total":  142,
  "limit":  20,
  "offset": 0
}

Naming conventions

Query parameters, request body fields, and response field names use snake_case. Existing camelCase aliases on list filters (widgetId, assignedTo, leadId, updatedSince) and on PATCH bodies (jobTitle, assignedTo) continue to work for one major version — new code should use snake_case.

Rate limits

Developer keys are rate-limited per key: 100 reads/min and 30 writes/min. Every authenticated response carries the current state in headers so well-behaved clients can self-throttle:

Quincer-RateLimit-Limit: 100
Quincer-RateLimit-Remaining: 87
Quincer-RateLimit-Reset: 1714435260

Over the limit returns 429 Too Many Requests with both the standard Retry-After header (seconds until reset) and the Quincer-RateLimit-* headers. The error body indicates the remaining count.

HTTP/1.1 429 Too Many Requests
Retry-After: 42
Quincer-RateLimit-Limit: 100
Quincer-RateLimit-Remaining: 0
Quincer-RateLimit-Reset: 1714435260

{
  "error": "Rate limit exceeded. 0 read requests remaining. Retry after 42 seconds."
}

Webhooks

Subscribe to events under Dashboard → Settings → Webhooks. Quincer AI signs every payload with HMAC-SHA256 using the secret you set. Requests include Quincer-Signature (sha256=...), Quincer-Event, and Quincer-Timestamp. The legacy X-Quincer-* variants are also sent for one major version (RFC 6648 deprecated the X- prefix — existing subscribers reading X-Quincer-* keep working unchanged).

Events

Verifying signatures

const signature = req.headers["quincer-signature"];
// (or "x-quincer-signature" if you set up your webhook before April 2026)
const expected = "sha256=" + crypto
  .createHmac("sha256", process.env.QUINCER_WEBHOOK_SECRET)
  .update(req.rawBody)
  .digest("hex");
if (signature !== expected) {
  return res.status(401).send("invalid signature");
}

OpenClaw integration

Quincer AI ships a first-class OpenClaw skill so any OpenClaw agent can take over Quincer AI conversations, query leads, and log activity. Setup takes about a minute:

1. In Quincer AI, open Dashboard → Integrations → OpenClaw and click Connect OpenClaw. This creates a dedicated "OpenClaw" team member in your workspace and issues an API token bound to it.
2. Download SKILL.md and drop it in ~/.openclaw/workspace/skills/quincer/.
3. Add the token to ~/.openclaw/openclaw.json under skills.entries.quincer.env.QUINCER_API_KEY.
4. Restart the OpenClaw gateway. The quincer tool is now available.

OpenClaw actions (takeovers, replies) appear in your Quincer AI inbox under the OpenClaw team member, with their own avatar and audit trail — not as a generic "external agent."