Customer support
API, webhooks, or BYOD: which integration do you need?
Three ways to connect initdesk to your stack—and only one of them is the new API, live today at developers.initdesk.com.
If you have read initdesk marketing, you have probably seen “connect any API.” That usually means Bring Your Own Data (BYOD): initdesk calls your endpoint so agents see plan tier, order history, or usage next to a ticket.
Today we are launching something different: the initdesk API and developer docs at developers.initdesk.com. Your systems can now call initdesk at
https://api.initdesk.com to read and write tickets, requesters, conversations, and Help Center content—the supported surface for CRMs, internal tools, automation, and custom portals.Three integration paths. Three directions of data. Pick by who initiates the HTTP request, not by buzzword.
Three directions (quick map)
| Integration | Who calls whom | Best for |
|---|---|---|
| API (new today) | You → initdesk (api.initdesk.com) | Create or list tickets, sync Help Center, CRM and internal tools |
| Webhooks | initdesk → your HTTPS URL | Real-time reactions when messages, assignments, or status change |
| BYOD | initdesk → your customer endpoint | Live customer context in the ticket sidebar and AI drafts |
None of these replaces the others. Many teams use BYOD plus the API: context beside the thread, tickets created from the product. Webhooks plus the API is common when you need an event to trigger a job that then fetches full ticket detail.
When to use the API
The API is the right default when your code needs to read or change initdesk data on demand.
Typical jobs:
- Create tickets from an in-app “Contact support” flow, a CRM, or an internal ops tool (you choose the inbox; the requester is a customer in API terms).
- List or search tickets for dashboards, SLA reports, or escalation digests you own.
- Read or post messages when you are building a custom portal or mirroring threads elsewhere.
- Publish or update Help Center articles and collections from a repo, CMS, or release pipeline.
Everything is scoped under one organization:
/organizations/{organization_id}/...
Use the numeric organization ID from Settings → General (not the string
public_id used in product URLs). Authenticate with an org-scoped token on every request:X-Initdesk-Token: <your_token>
Issue tokens under Settings → API access (Account Owner or Admin). The raw value is shown once—store it like a password and revoke if it leaks. Full auth, rate limits, and entity relationships live in the developer docs and entities guide.
The OpenAPI schema is at api.initdesk.com/schema.yaml. For a minimal first call, see Connect to the initdesk API in 15 minutes—published today alongside this post.
What the API is not: a replacement for native product integrations. Linear issue create/link still runs in the initdesk UI and plugin layer; there is no Linear resource in the API today. The workflow in Linear issues from support tickets still applies—use the API for ticket and message data, not for filing issues in Linear.
When webhooks are enough
Choose webhooks when initdesk should push you an event and your job is to react—notify Slack, kick off n8n, invalidate a cache, or append a row to an analytics table.
Configure them in Settings → API & Webhooks. Pick the events you care about (for example message created, assigned, resolved, status changed). Your endpoint should return a 2xx response within about five seconds or delivery may be marked failed.
Webhooks carry notifications, not a full export of your account. If you need structured ticket bodies, assignees, or Help Center fields on demand, use the API (or combine: webhook wakes your worker, API supplies the payload).
Product reference: Webhooks in initdesk Help Center.
When BYOD is the right fit
BYOD is for customer context at reply time: billing status, subscription plan, last order, feature flags—whatever lives in your admin API.
initdesk POSTs to your HTTPS endpoint (with optional auth headers you configure) and renders the response in the ticket sidebar using Liquid templates. That same data can inform AI draft replies, so agents are not guessing from subject lines alone.
BYOD does not create tickets, list your inbox, or publish help articles. It does not replace the API—and the API does not pull arbitrary data from your systems into the sidebar. For that split, see Bring Your Own Data on initdesk Updates and the BYOD plugin guide.
Common combinations (and one anti-pattern)
BYOD + API create ticket — A customer opens support from your app; you
POST a ticket with their email and subject. When an agent opens the thread, BYOD already loaded account context beside it.Webhook + API retrieve — A “message created” webhook triggers your worker; the worker calls retrieve ticket and list messages for the full thread before posting to an internal channel.
Help Center API + editorial habits — You sync articles from git; agents still follow the content patterns in Self-service that actually gets used so search and AI chat stay trustworthy.
Anti-pattern: rebuilding initdesk in your database — Polling the API into a shadow inbox duplicates assignee state, internal notes, and spam handling you already paid for in the product. Prefer webhooks or targeted reads for the views you actually need.
Where to go next
- Developer docs (live today): developers.initdesk.com
- First API call: Getting started with the initdesk API
- Access or beta questions: [email protected]
initdesk is an AI help desk for small teams: shared inbox, Help Center, BYOD, webhooks, and—as of today—a API for tickets, requesters, messages, and Help Center content. See Product Updates for launch notes and X @initdeskhq for announcements.