Ticket sources
Connecting HubSpot, Zendesk or Jira as the inbox — which credential each one takes, and what to do when the deployment is self-hosted.
A ticket source is where the inbox comes from. Integrations let the agent read your systems; a ticket source is the thing it is reading about.
Each source is configured on the desktop Integrations page, under Ticket sources. Ingest is webhook-first with a poller behind it, so a source works with only the credential filled in — the webhook secret makes it immediate rather than every two minutes.
Saving runs a connection test. If it fails you can still Save anyway, which is what you want when the failure is a network detail you are about to fix.
HubSpot
| Field | Required | What to put |
|---|---|---|
| Access token | yes | A private app token — Settings → Integrations → Private apps — or an OAuth access token from your own HubSpot app. Both work in this one field. It needs the tickets read scope. |
| Webhook secret | no | The app's client secret. Leave it empty for a poll-only setup; without it, inbound webhooks are rejected. |
| API base path | no | Empty for api.hubapi.com. Point it at a mock server for testing. |
A private app token and an OAuth token are the same credential
HubSpot implements private app tokens on top of OAuth, and both are sent as
Authorization: Bearer. There is no second field to pick between them because there is
nothing on the wire to distinguish.
Zendesk
Pick the authentication method. The Authentication method select changes which fields appear; the other method's fields are hidden, are not required, and are dropped when you save.
- API token — agent email + token. What most existing connections use.
- OAuth access token. Prefer this for a new connection, for the reason below.
Create the credential.
API token: Admin Center → Apps and integrations → APIs → Zendesk API, then add
a token. It is sent as basic auth over {email}/token:{token} and carries the full
permissions of the agent account whose email you enter beside it.
OAuth access token: an access token issued by a Zendesk OAuth client in your
account (Admin Center → Apps and integrations → APIs → OAuth clients). Reading
tickets needs the read scope. Paste the access token itself, not the client secret.
An OAuth access token expires, and nothing here renews it
Triagic does not run the browser authorization flow, so the token you paste is the token it keeps using. The connector stops when that token expires.
Fill in the fields.
| Field | Required | What to put |
|---|---|---|
| Subdomain | yes | Just the subdomain — for https://acme.zendesk.com that is acme, not the URL. |
| Authentication method | no, defaults to API token | Which of the two above. |
| API token only | The agent account the token was created under. Its permissions are the ones this connector gets. | |
| API token | API token only | |
| OAuth access token | OAuth only | Sent as Authorization: Bearer. |
| Webhook secret | no | The webhook signing secret, shown once when you create the webhook. Without it, inbound webhooks are rejected and only the poller runs. |
Why OAuth is worth the extra step
Zendesk marks the API-token scheme deprecated, and its own warning says why: an API token can be used to impersonate anyone in the account. An OAuth token carries only the scopes it was granted. Both still work — this is a reason to choose, not a deadline.
Zendesk has no self-hosted product and every URL is built from the subdomain, so there is no host, CA-certificate or verify-TLS field on this form.
Jira
Jira Cloud and Jira Server / Data Center differ in more than the credential: they serve
different REST versions, and Data Center does not have the search endpoints Cloud added.
The Authentication method select is what tells Triagic which one it is talking to,
so a mismatch here fails at the first request with a 401.
Pick the deployment.
- Cloud — email + API token. An
*.atlassian.netsite. The default. - Server / Data Center — personal access token. Self-hosted. These instances cannot issue Atlassian API tokens at all, and take a bare bearer token with no email beside it.
Create the credential.
Cloud: an API token at id.atlassian.com → Security → API tokens. It acts as the Atlassian account it belongs to, so use an account whose project permissions are the ones you want.
Server / Data Center: a personal access token from the account's own profile — Profile → Personal Access Tokens → Create token. Jira needs 8.14 or newer; older versions have no such screen. There is no email field to fill in: the token identifies its own owner and inherits that account's project permissions.
Fill in the fields.
| Field | Required | What to put |
|---|---|---|
| Base URL | yes | https://acme.atlassian.net for Cloud; whatever host serves your instance for Data Center, e.g. https://jira.acme.internal. |
| Authentication method | no, defaults to Cloud | Which deployment this is. |
| Cloud only | The Atlassian account the API token belongs to. | |
| API token | Cloud only | |
| Personal access token | Data Center only | Sent as Authorization: Bearer, with no email. |
| Webhook secret | no | HMAC secret for a system webhook, checked against X-Hub-Signature. |
| URL token | no | Fallback for instances that cannot sign: a shared token passed as ?token= on the webhook URL. |
| CA certificate path | no | A Data Center instance behind a private CA. An absolute path on the machine running Triagic to that CA's PEM bundle. It applies to this connector alone. |
| Verify TLS certificate | no, defaults on | Turn off only for a self-signed instance you cannot supply a CA bundle for. |
Configure one of the two webhook fields or neither. With neither, the connector falls back to polling — inbound webhooks are rejected, because an unauthenticated one cannot be attributed to your organization.
When something goes wrong
| If it reports | It usually means |
|---|---|
401 on a Data Center URL | The method is still set to Cloud. Data Center does not accept an email and API token at all. |
401 on an *.atlassian.net URL | The method is set to Data Center, or the token was created under a different account than the email names. |
HTTP 404 from search | The base URL is right but reaches something other than Jira — check for a path prefix or a reverse proxy rewriting the request. |
| A certificate error rather than a Jira error | The instance's certificate is not trusted by that machine. Set CA certificate path, or turn off Verify TLS certificate. |
| A picker is empty but polling works | That lookup is not available on your Jira version. Use Raw JQL instead — it replaces every picker. |
Filters
Every source carries filters below the connection fields, and they gate both paths: a webhook that does not match is dropped, exactly like a polled ticket that does not match. The one exception is Jira's Raw JQL escape hatch — it can express anything, so it is not re-implemented for webhooks, and a config that uses it leaves webhook ingest unfiltered.