The Pattern Every Developer Recognizes
Your team picks a support platform. It works. Then product asks for a custom ticket form. Design wants the help center to match your brand. Engineering needs ticket data piped into an internal dashboard.
And now you're reverse-engineering undocumented APIs, scraping widget HTML, or -- worst case -- copy-pasting ticket data between browser tabs like it's 2008. The platform that was supposed to save time became the bottleneck.
I lived this for a decade. Built workarounds on workarounds. Wrote scrapers to extract data from tools that were supposed to be helping me. At some point you stop patching the wall and build a new house.
Headless Means the API Is the Product
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, real-time events, SLA tracking, and the gamification engine that keeps your agents from burning out.
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?
Everything Below Is Live
Not "coming soon." Not "join the waitlist." Ship it or don't talk about it. This is the way.
REST API
Full CRUD on every resource. Prefixed IDs (tkt_, cus_, art_, msg_, whk_) so you never confuse entity types -- because debugging "which kind of ID is a7f3b2c1?" at 2 AM is a quest nobody asked for.
curl https://www.cstar.help/api/v1/teams/{teamId}/tickets \
-H "Authorization: Bearer sk_live_your_key" \
-H "Content-Type: application/json"
Consistent envelope responses with success, data, and meta on every call. Pagination, filtering, sorting -- all built in, all identical across endpoints. 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 reads. Test mode gives you a complete sandbox. Separate data, same API.
Three SDKs
Official clients for the frameworks developers actually use:
@cstar.help/js-- The core. Node.js, Deno, Bun, 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$stateand$derived. Reactive data fetching that feels native to the framework, not bolted on. ~15 KB.
All fully typed with TypeScript. React and Svelte SDKs include the JS client as a dependency -- one install, done.
Webhooks
Subscribe to ticket.created, customer.updated, boss.defeated (yes, really -- boss battles are part of the data model), and dozens more. Every delivery is HMAC-signed with a whsec_ secret. 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 dev companion. Think of it as a warp zone straight to your support data:
cstar listen-- Forward webhook events to your local dev server. No ngrok needed.cstar logs --tail-- Stream 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
This is the part that made me grin when we shipped it.
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 through natural language.
{
"mcpServers": {
"cstar": {
"command": "npx",
"args": ["@cstar.help/cli", "mcp-server", "--stdio"]
}
}
}
Your AI pair programmer just became your AI support agent. "Show me all high-priority tickets from this week" works. "Create a customer and open a ticket for them" works. It's the kind of thing that feels like science fiction until you watch it happen in your terminal, and then it just feels obvious -- like, of course this is how it should work.
Identity Verification
For customer-facing widgets and portals, you need to prove a user is who they claim to be. HMAC-SHA256 identity verification -- your server signs the customer's email with your secret key, 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'll save you debugging time: 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. Because HMAC mismatches at midnight are nobody's idea of an adventure.
Idempotency Built In
Every write endpoint supports idempotency keys. Send the same Idempotency-Key header twice, 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 API-First Beats API-Bolted-On
Bolting an API onto a UI-first product always feels like an afterthought. You end up with created_at on one endpoint and createdAt on another. Pagination that works differently depending on the resource. Error responses that change shape like a Ditto. Rate limits hidden behind "contact sales."
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 we added. It's the foundation everything else stands on.
Gamification Through the API
Here's what separates cStar from yet another headless API: your agents don't just use it -- they play it.
Every ticket resolution earns XP. Streaks build momentum. SLA bosses spawn when response times are at risk. And all of it is exposed through the API. boss.spawned, boss.defeated, achievement.unlocked -- real webhook events you can subscribe to.
Build a team dashboard showing live boss battles. Pipe achievement data into Slack. Display a leaderboard on the office TV. The gamification isn't a cosmetic layer. It's part of the data model. 10 billion percent baked in.
$15/seat. That's It. That's the Pitch.
No API tier. No webhook add-on. No "developer plan" at 3x the price. Every cStar seat includes full API access, all three SDKs, webhooks, CLI, and MCP server mode.
The developer platform ships with every account because we believe every support team deserves developer-grade tools. Not just the ones with enterprise budgets.
Go Build Something
The fastest path from zero to API call:
- Create a cStar account and team
- Grab an API key from team settings (or
cstar keys create) npm install @cstar.help/js- 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.
Go build something we haven't thought of yet. That's the whole point.
Written by Josh Lopez. He has mass-pinged himself in Slack using the MCP server more times than he'd like to admit.