API and integrations

A web API over the whole product

The API is not a cut-down slice of the product. It covers tickets, customers, help articles, rules, reports, settings and the rest, because the screens are built on it.

• About 3,800 operationsAcross 53 parts of the system
• A machine-readable list of every callAn OpenAPI 3.1 file you can download. It is generated from the code when you ask for it, so it cannot fall behind what the API really does.
• Every call names the permission it needsEach operation is tagged with its required permission and the key scopes it accepts
• A reference list inside the productSearch it, and press a try-it button on simple read calls
• Eleven written guidesGetting started, the app manifest, the app kit, events, OAuth, MCP, the edge connector, channels, customer sign-in tokens, importers and limits
• OAuth apps of your ownServer or browser type, return addresses, scopes, and a secret you can rotate
• Three token flowsClient credentials, authorization code, and refresh tokens that rotate. Reusing an old refresh token kills the whole chain.
• Sign your own users inSend a signed token from your site, by shared secret or a JWKS address, with two keys live at once so you can rotate
• Let outside AI tools connect over MCPSix tools: search tickets, read one, draft a reply as a private note, update a ticket, search help articles, and ask our AI agent. The first five work on their own; anything that writes AI text needs your own account with an AI provider, and is switched off on our demo.

API keys, limits and who may use them

Keys are not an afterthought here. A key carries scopes, an expiry and an address list, and an admin key needs a second admin to agree to it.

• Ten scopes per keyPlus an expiry date and a list of IP addresses allowed to use it. The full key is shown once.
• A second admin approves any admin keyOne admin asks, a different one approves or rejects. The key does not work until then.
• Rate limits by plan60, 200, 1,000 or 4,000 requests a minute, with bursts. Replies carry rate-limit and retry-after headers.
• Usage you can readRequests a day per key, split into client errors, server errors and throttled calls, with each key's last-used time and address
• Personal tokensNever more access than the person already has, and never the admin scope
• Your own developer policyWhether personal tokens are allowed, the longest token life, the default key life, and developer features on or off
• An address allow-listOne that covers every API key, and a separate one for developers
• Keys expire after a year by defaultYou can change that default
• Revoke a keyBehind a typed confirmation, so it is not a slip of the mouse

Messages pushed to your systems

You do not have to poll us. Give us an address and we send you a message when something happens, signed so you know it came from us, and we keep trying if your end is down.

• 16 eventsTicket created, updated, status changed, assigned, merged, deleted, restored and marked as spam; message added; customer created, updated, merged and deleted; company changed; and reply-time warning and reply-time missed
• Signed with HMAC-SHA256Over a timestamp and the body, accepted within 300 seconds, so a captured message cannot be replayed at you later
• Rotate the secret without downtimeThe old secret keeps working for 24 hours
• Retried five timesAfter 1 minute, 5 minutes, 30 minutes, 2 hours and 6 hours
• Switched off by itself if it keeps failingAfter however many failures in a row you allow
• A delivery logKept 7 to 90 days. Open a delivery to read exactly what we sent and what came back.
• A replay buttonReplay one delivery, or every failed delivery on that webhook in one go
• Send a test eventBefore you have written a line of code
• An extra auth headerStored encrypted, if your endpoint needs one. Addresses must be https.
• Instant triggers for Zapier and MakeSubscribe and unsubscribe REST hooks, with a sample payload for each event. We have not published an app in either directory, so you wire it up yourself.

Apps that add a panel beside the ticket

There is a framework for putting your own screen next to a ticket: you declare what it needs, we sign the request, your app answers. Read the note below before you plan work around it.

• Build a private app in three stepsName and id, where it shows, then address and scopes
• Register a panel appIts address, which websites may host it, which ticket fields it receives, which roles see it, and a signing secret
• Install your own app in your own workspaceSo you can test it before anyone else sees it
• Send a version for reviewWith a data and security questionnaire. We approve it, send it back or reject it with a reason you can read.
• A catalogue of 47 appsSearch and categories, each card showing the version, the price and whether it is installed
• Read what an app is asking forThe access it wants, its settings, a consent tick, then install
• Uninstall cleanlyBehind a typed confirmation, taking its saved settings and keys with it
• Keys for your own appsiOS, Android and web keys for the messaging kit, with pause, remove, and a 24-hour overlap when you rotate the secret

Connecting the tools you already run

A catalogue of 47 connections covering issue trackers, shops, customer records, phones, billing, device management, status pages, HR, documents, build servers and equipment lists. Each needs your own account with that tool.

• Call an outside service from a ruleBearer, basic, API-key or OAuth2 auth, a field map, retries and a timeout, limited to hosts you have allowed
• Write your own code as a rule stepIt runs in a locked worker thread with no network access and a cap on processor time and memory
• Reusable message templatesFor chat and text messages, with a preview
• A delivery log for chat and textSo you can see what was sent where
• Switch early-access features on and offPer workspace, from the integrations screen

Trying a change before it goes live

You can take a copy of your set-up, change it, compare the two, then push over only the parts you want.

• A sandbox from your live settingsOr from a snapshot you saved earlier, with sample tickets in it
• Snapshots of your set-upSave one with a note, download it, or delete it
• Compare two set-upsLive against a snapshot or a sandbox, with the differences listed
• Deploy only the ticked changesNot the whole set-up in one lump
• A deploy history, and roll one backSo a bad change is a minute's work to undo
• Find rules that never ranA list of rules that have never fired, overlap each other, or are still drafts

Getting your data in and out

• Export tickets and messages, and customersAs CSV or JSON, with your password typed again, a link that lasts 7 days, and one export running at a time
• Export tickets from the ticket screenCSV or JSON, with or without customer personal details, and the reason recorded
• Import tickets from a fileCSV or JSON, with ready column presets for Zendesk, Freshdesk, Help Scout and Zammad
• Import customers and companiesMatch the columns, see the first rows, then choose to skip, update or re-add anyone already here
• Import help articlesFrom a Zendesk export zip, a Freshdesk CSV, a Help Scout zip, an HTML zip or a CSV
• Try every import firstA practice run that saves nothing, then a downloadable list of the rows that would fail

Moving from another help desk is the long version of this. Read how the import works, including the quiet mode that sends no email to your customers while it runs.