Unified Ticketing API

What Is a Unified Ticketing API?

A unified ticketing API is a single, standardized programming interface that lets your product read and write ticket, comment, and contact data across multiple ticketing platforms without building a separate integration for each one.

Ticketing platforms each expose their own APIs with different field names, status taxonomies, and pagination models. Knit normalizes these differences so your engineering team integrates once, and Knit handles the translation layer for every ticketing tool your customers use.

Knit normalizes three things across all providers:

How It Works

1. Your customer connects their ticketing platform
Knit's pre-built embedded auth UI handles OAuth and token management per provider. Your team writes zero auth code.

2. Knit normalizes the data
Tickets, contacts, accounts, and comments are all mapped to Knit's unified schema, regardless of how each platform stores or names them internally.

3. Your product calls one API
Use a single set of endpoints and data models across your entire product. Add a new ticketing platform later? No code changes on your side.

4. Stay in sync with real-time webhooks
Native and virtual webhooks fire on ticket changes, such as status updates, new comments, or reassignment, with a consistent event schema across all providers.

Ticketing Data Objects

The following objects are available through the unified schema. All fields are normalized across providers.

Tickets

The core work-item object: a support ticket, a Jira issue, a GitHub issue, or an Asana task, normalized to one schema.

id, createdAt, updatedAt, name, assignedToId, createdById, dueDate,
status, description, ticketType: { typeId, typeName }, accountId,
projectId, groupId, contactIds[], priority, source, url, tags[]

Filterable by accountId, contactId, assignedToId, status, tag, ticketType, collectionId, and created/updated/due date ranges. projectId is the field that makes this object work for issue trackers like Jira and GitHub as well as helpdesk tools.

→ Get tickets · Get ticket by ID · Create ticket · Update ticket

Comments

Replies and internal notes attached to a ticket, including attachments and public/private visibility.

id, createdAt, body, htmlBody, isPublic,
author: { type, id }, attachments[]: { id, createdAt, name, content, encoding, url }

author.type distinguishes a contact (external requester) from a user (internal agent) as the comment's source. isPublic matters for helpdesk platforms where internal notes shouldn't be customer-visible.

→ Get comments for a ticket · Add comment to a ticket

Accounts & Contacts

The organization (Account) and the individual (Contact) a ticket is raised on behalf of, standard in helpdesk platforms.

Account:  id, name, createdAt, website, industry
Contact:  id, name, createdAt, emailAddress, phoneNumber, accountId

For GitHub specifically, accountId and collectionId are required parameters on several endpoints since GitHub's structure (organizations, repositories) doesn't map cleanly to the Account/Contact model helpdesk tools use.

→ Get accounts · Get account by ID · Get contacts · Get contact by ID

Users & Groups

Agents and team members configured in the connected platform, and the groups used for ticket routing.

User:   id, name, email, role
Group:  id, name, description, isPublic, userIds[]

→ Get users · Get user by ID · Get groups · Get group by ID

Tags, Ticket Types & Collections

Supporting reference objects used to classify and organize tickets.

Tags:          flat list of applicable tag strings
Ticket Types:  typeId, typeName
Collections:   groupings used to organize tickets and knowledge base articles

→ Get tags · Get all ticket types · Get collections

API Reference

All ticketing endpoints are organized by category. Each endpoint works identically regardless of the underlying platform. Pass your API key and the customer's X-Integration-Id, and the response schema is consistent across all providers.

Ticket APIs

Comment APIs

Account & Contact APIs

User & Group APIs

Reference Data APIs

Supported Platforms

Knit connects to ten ticketing, helpdesk, and issue-tracking platforms.

Don't see a platform? Use the Connector Builder / Integration Agent to add it yourself in hours, not weeks.

Key Capabilities

Real-Time Sync & Webhooks

Knit supports both native webhooks (forwarded directly from platforms that emit them) and virtual webhooks (Knit polls the source, detects changes, and emits events). Both use the same subscription interface and event schema, so your integration code is identical either way.

Supported event types include: record.new, record.modified, record.deleted, and more.

Zero Data Storage

Knit never stores your customers' ticket data at rest. Every API request passes through to the source platform in real time. This reduces your GDPR, CCPA, and SOC 2 compliance scope, since there are no replicated tickets sitting in a third-party system.

One Model for Support Tickets and Issues

The same projectId and ticketType fields that support a Jira epic or a GitHub repository also work for a Zendesk ticket's queue and category, so your product can build one workflow that spans customer support and engineering without separate data models.

AI Connector Builder / Integration Agent

When a customer's ticketing platform isn't in Knit's library, the AI Connector Builder lets your team define a new connector in hours. Specify the platform's API structure and data mapping; Knit's AI generates the connector.

Passthrough API

Need a field outside the unified APIs, like a ServiceNow-specific CI reference or a Jira custom field? Passthrough lets you make direct calls to the underlying platform using Knit's authentication layer.

MCP Compatibility

Knit is MCP-compatible, giving AI agents authenticated read/write access to tickets, comments, and contacts across every connected platform through the same unified layer, with no per-provider auth or endpoint logic in your agent code.

Quick Start

Authentication

All requests require two headers:

Authorization: Bearer YOUR_API_KEY
X-Integration-Id: YOUR_CUSTOMER_INTEGRATION_ID

The X-Integration-Id is the unique identifier for a specific customer's connected ticketing platform, issued after they complete the Knit auth flow.

Fetch tickets

curl --request GET \
     --url 'https://api.getknit.dev/v1.0/ticketing/tickets.list?status=OPEN' \
     --header 'accept: application/json' \
     --header 'Authorization: Bearer YOUR_API_KEY' \
     --header 'X-Knit-Integration-Id: YOUR_CUSTOMER_INTEGRATION_ID'

Response: same schema whether the customer uses Zendesk, Jira, or GitHub:

{
  "success": true,
  "data": {
    "pagination": { "next": "next cursor", "previous": "previous cursor" },
    "tickets": [
      {
        "id": "the ticket Id",
        "createdAt": "2026-08-01T00:00:00Z",
        "updatedAt": "2026-08-15T00:00:00Z",
        "name": "Customer cannot reset password",
        "assignedToId": "agent_123",
        "status": "OPEN",
        "description": "Customer reports reset link returns a 404",
        "ticketType": { "typeId": "TYPE_1", "typeName": "Bug" },
        "accountId": "account_456",
        "contactIds": ["contact_789"],
        "priority": "HIGH",
        "source": "email",
        "tags": ["password", "urgent"]
      }
    ]
  }
}

Create a ticket

curl --request POST \
     --url https://api.getknit.dev/v1.0/ticketing/ticket.create \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --header 'Authorization: Bearer YOUR_API_KEY' \
     --header 'X-Knit-Integration-Id: YOUR_CUSTOMER_INTEGRATION_ID' \
     --data '
{
  "name": "Customer cannot reset password",
  "description": "Customer reports reset link returns a 404",
  "priority": "HIGH",
  "contactIds": ["contact_789"],
  "tags": ["password", "urgent"]
}'

Add a comment

curl --request POST \
     --url https://api.getknit.dev/v1.0/ticketing/ticket.comment.add \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --header 'Authorization: Bearer YOUR_API_KEY' \
     --header 'X-Knit-Integration-Id: YOUR_CUSTOMER_INTEGRATION_ID'

Use Cases

Embedded Customer Support

Let users raise, view, and comment on support tickets directly inside your product, regardless of whether your customer runs Zendesk, Intercom, or Freshdesk on the back end.

Typical flow: create ticket on user submission → poll or webhook on status change → surface agent replies via comments endpoint inside your UI

AI Support Agents & Triage

Feed normalized ticket and comment data into LLM pipelines and MCP-compatible agents to build support copilots that draft replies, auto-tag, or route tickets across whichever helpdesk a customer runs.

Typical flow: sync tickets + comments → embed into vector store → ground LLM triage suggestions in ticket context → use MCP tools to update status or add a comment

Engineering-to-Support Handoff

Bridge customer support and engineering by linking a Zendesk ticket to a Jira issue or GitHub issue in the same unified model, without building separate integrations for each pairing.

Typical flow: record.new webhook on support ticket → create linked issue in the engineering tracker via the same Ticket object → sync status changes bidirectionally

Unified Work Item Reporting

Aggregate ticket and issue volume, status, and resolution time across support and engineering tools into one reporting layer, useful for teams running Zendesk for support and Linear or Jira for engineering.

Typical flow: fetch tickets across connected platforms by date range → normalize status and priority values → aggregate into a single dashboard

Customer Health & Escalation Tracking

Combine the Unified Ticketing API with Knit's Unified CRM API to surface ticket volume and severity alongside account and deal data for customer success and account management workflows.

Typical flow: fetch tickets by accountId → join with CRM company and deal records → flag accounts with rising ticket volume or high-priority tickets

FAQ

What is a unified ticketing API?
A unified ticketing API is a single, standardized interface that lets your product read and write tickets, comments, and contact data across multiple ticketing platforms without building a separate integration for each one.

Is this about event ticketing, like concert or travel tickets?
No. Knit's Unified Ticketing API is for support tickets and work items: customer support requests, engineering issues, and tasks. It has no connection to event-ticketing platforms like Ticketmaster or StubHub.

Does this only cover customer support helpdesks?
No. The connector list spans customer support tools (Zendesk, Intercom, Freshdesk, Zoho Desk, Freshservice, ServiceNow) and engineering issue trackers and work-management tools (GitHub, Jira, Linear, Asana). The underlying Ticket object is the same shape across both.

How long does it take to integrate?
Most teams go live in 1–3 days with Knit. Building a production-ready 1:1 native integration against a single platform like Zendesk typically takes several weeks. When you build with Knit, one integration gives you access to every connected ticketing platform, and Knit maintains all connectors as providers update their APIs.

Does Knit store ticket data?
No. Knit is a pass-through layer: requests hit the source platform in real time and no data is stored at rest. This reduces your GDPR, CCPA, and SOC 2 compliance scope.

Why do some GitHub endpoints need an accountId or collectionId?
GitHub's structure, organizations and repositories, doesn't map directly onto the Account/Contact model that helpdesk platforms use. A handful of endpoints (comments, groups) require you to pass the correct GitHub account or collection ID explicitly, which you can retrieve via the Get Accounts and Get Collections endpoints.

What if a customer's ticketing platform isn't on the list?
Using the Connector Builder, we can add a new connector in hours.

Is Knit compatible with AI agents and MCP?
Yes. Knit is MCP-compatible, so agents in MCP-compatible frameworks can perform authenticated ticketing read/write actions via Knit with no per-provider logic.

What's the passthrough API?
The passthrough API lets you make direct calls to the underlying ticketing platform using Knit's authentication layer. Use it for fields outside the unified schema.

Next Steps