Introducing cStar's Headless Developer Platform: Customer Support, Unchained

Support Software Has a Developer Problem

Here's a pattern every developer knows: your team picks a support platform. It works okay at first. Then product asks for a custom ticket form. Or design wants the help center to match your brand. Or engineering needs ticket data piped into an internal dashboard.

And suddenly you're fighting the platform instead of building on it.

You're reverse-engineering undocumented APIs, scraping widget HTML, or — worst case — copy-pasting ticket data between tabs like it's 2008. The platform that was supposed to save time is now the bottleneck.

We've been there. For a decade. And we decided to build the platform we wished existed.

What "Headless" Means for Customer Support

Headless means the API is the product. There's no widget you're forced to embed. No iframe wrestling. No "enterprise plan required" to access your own data.

cStar gives you a complete REST API for tickets, customers, knowledge base articles, messages, and webhooks. You build the frontend. You control every pixel. We handle the data layer, the real-time events, the SLA tracking, and the gamification engine that keeps your agents engaged.

Think of it like Stripe for support — you wouldn't want Stripe to own your checkout page. Why let a support platform own your help experience?

What Ships Today

This isn't a "coming soon" blog post. Everything below is live, documented, and tested.

REST API

Full CRUD on every resource. Prefixed IDs (tkt_, cus_, art_, msg_, whk_) so you never confuse entity types. Consistent envelope responses with success, data, and meta on every call. Pagination, filtering, and sorting built in.

curl https://www.cstar.help/api/v1/teams/{teamId}/tickets \
  -H "Authorization: Bearer sk_live_your_key" \
  -H "Content-Type: application/json"

Two key types: secret keys (sk_live_, sk_test_) for full server-side access, and publishable keys (pk_live_, pk_test_) for safe client-side read operations. Test mode with sk_test_ keys gives you a complete sandbox — separate data, same API.

Three SDKs

We ship official clients for the frameworks developers actually use:

• @cstar.help/js — The core. Works in Node.js, Deno, Bun, and browsers. Zero dependencies beyond fetch. ~12 KB.
• @cstar.help/react — React hooks wrapping the JS client. useTickets(), useCustomers(), automatic loading states, SSR-safe. ~18 KB.
• @cstar.help/svelte — Svelte 5 rune classes using $state and $derived. Reactive data fetching that feels native. ~15 KB.

All three are fully typed with TypeScript. The React and Svelte SDKs include the JS client as a dependency — you never install two packages.

Webhooks

Subscribe to ticket.created, customer.updated, boss.defeated (yes, really), and dozens more. Every webhook delivery is HMAC-signed with a whsec_ secret, so you can verify payloads are genuinely from cStar. Failed deliveries retry with exponential backoff.

// Verify a webhook signature
const crypto = require("crypto");
const signature = crypto
  .createHmac("sha256", webhookSecret)
  .update(rawBody)
  .digest("hex");

if (signature === req.headers["x-cstar-signature"]) {
  // Legitimate webhook — process it
}

CLI

The cstar CLI is your local development companion:

• cstar listen — Forward webhook events to your local dev server. No ngrok needed.
• cstar logs --tail — Stream your API request logs in real-time.
• cstar trigger ticket.created — Fire test events to all your webhook endpoints.
• cstar keys create — Manage API keys without touching the dashboard.

npm install -g @cstar.help/cli
cstar login --api-key sk_test_your_key
cstar listen --forward-to http://localhost:3000/api/webhooks

MCP Server Mode

The CLI doubles as an MCP (Model Context Protocol) server. Add it to Claude Code or any MCP-compatible AI tool, and your AI agent can list tickets, create customers, search articles, and trigger webhooks — all through natural language.

{
  "mcpServers": {
    "cstar": {
      "command": "npx",
      "args": ["@cstar.help/cli", "mcp-server", "--stdio"]
    }
  }
}

Your AI pair programmer just became your AI support agent.

Identity Verification

For customer-facing widgets and portals, you need to prove a user is who they claim to be. cStar uses HMAC-SHA256 identity verification — your server signs the customer's email with your secret key, and our API verifies it.

// Server-side: generate identity hash
const hash = crypto
  .createHmac("sha256", secretKey)
  .update(JSON.stringify({ email: user.email }))
  .digest("hex");

// Client-side: pass hash with API calls
const cstar = new CStarClient({
  apiKey: "pk_live_your_key",
  identity: { email: user.email, hash }
});

One detail that matters: the payload must be compact JSON (no spaces after colons or commas). We surface the exact expected payload string in test mode error messages, along with code snippets for Python, Ruby, and PHP, so you're never stuck debugging HMAC mismatches.

Idempotency Built In

Every write endpoint supports idempotency keys. Send the same Idempotency-Key header twice and you'll get the exact same response — same envelope, same request ID, with a meta.idempotentReplayed: true flag so you know it was cached. Keys expire after 24 hours.

curl -X POST https://www.cstar.help/api/v1/teams/{teamId}/tickets \
  -H "Authorization: Bearer sk_live_your_key" \
  -H "Idempotency-Key: unique-request-id-123" \
  -H "Content-Type: application/json" \
  -d '{"title": "Network issue", "priority": "high"}'

Safe retries without duplicate tickets. Your webhook handlers and queue consumers will thank you.

Why Not Just Add an API to Existing Platforms?

Because bolting an API onto a UI-first product always feels like an afterthought. You end up with:

• Inconsistent field naming (is it created_at or createdAt?)
• Pagination that works differently on every endpoint
• Error responses that change shape depending on the error type
• Rate limits hidden behind "contact sales"
• Webhook payloads that don't match API responses

cStar was API-first from day one. Every field is camelCase. Every response has the same envelope. Every error has the same shape. Pagination works identically across tickets, customers, and articles. The API isn't a feature — it's the foundation.

The Part Where We Mention Gamification

Here's what makes cStar different from "yet another headless API": your agents don't just use it — they play it.

Under the hood, every ticket resolution earns XP. Streaks build momentum. SLA bosses spawn when response times are at risk. Your agents see an adventure where other platforms show a queue.

And it's all exposed via the API. boss.spawned, boss.defeated, achievement.unlocked — these are real webhook events you can subscribe to. Build a team dashboard that shows live boss battles. Pipe achievement data into Slack. The gamification isn't a gimmick bolted on top — it's part of the data model.

$15/seat. That's It.

No API tier. No webhook add-on. No "developer plan" that costs 3x more. Every cStar seat includes full API access, all three SDKs, webhooks, CLI, and MCP server mode.

We're not hiding enterprise pricing behind "contact sales." The developer platform ships with every account because we believe every support team deserves developer-grade tools.

Get Started

The fastest path from zero to API call:

1. Create a cStar account and team
2. Grab an API key from team settings (or cstar keys create)
3. npm install @cstar.help/js
4. Make your first request

import { CStarClient } from "@cstar.help/js";

const cstar = new CStarClient({
  apiKey: "sk_test_your_key"
});

const { data: tickets } = await cstar.tickets.list({
  status: "open"
});

console.log(`You have ${tickets.length} open tickets`);

Full documentation lives at /developers. The quickstart takes under 5 minutes. The API reference covers every endpoint, parameter, and response.

Go build something we haven't thought of yet. That's the whole point.