Connecting Zendesk, Freshdesk and Intercom

Three products connect with a pasteable credential today: Zendesk, Freshdesk and Intercom. The flow is the same for all three. This page walks it once, then covers testing and disconnecting.

Connecting is an admin action.

What you will need

Each provider asks for a small, fixed set of fields, and the connect form tells you where to find them.

Every form carries a How to get your credentials block with the steps for that product and a link to its documentation — for example, for Zendesk: Zendesk Admin → Apps & Integrations → Zendesk API → enable Token Access → create a new token. Read it rather than guessing at which of several similar-sounding secrets is wanted; the commonest failure is a token from the wrong place rather than a mistyped one.

Note that Intercom wants an access token, not an OAuth sign-in.

Connecting

Open the card, fill in the fields, submit.

That ordering is the useful part:

• If the test fails, nothing is saved. No secret, no connection row. The refusal carries the provider's own error message, so you are reading Zendesk's or Intercom's explanation rather than ours.
• Because nothing is written, a failed attempt cannot damage a connection that already works. Reconnecting is an overwrite, so this is what stops a typo from replacing a live credential with a broken one.

On success the credential is encrypted at rest — the connection row holds only a reference to it, never the secret — the connection appears in the connected list, and the account it belongs to is recorded from the test. You will see something like Jane Doe @ acme.zendesk.com on the row. Glance at that label: it is how you notice you have connected the sandbox account rather than the production one.

The action is written to the workspace audit log.

Nothing is ever pre-filled on a reconnect, because the runtime never returns a stored credential. The form says so: changing these replaces what is stored, and a field marked on file must be re-entered rather than left blank.

Testing an existing connection

Test connection, on a connected row's menu, re-runs the same check against the provider and writes the answer back. This is the only way a stored connection changes state, so it is the thing to press when something downstream is behaving as though the credential has expired.

It updates three things: the state (Connected or Action needed), the last error if there was one, and the account label — which is how you find out that somebody rotated the token or changed the account behind your back.

Disconnecting

Disconnect asks for confirmation and states the consequences plainly: the stored credential is deleted, anything in this workspace that reads through it stops working immediately, and reconnecting means entering the credential again because we cannot show it to you. There is no soft delete and no undo.

One refusal is worth knowing about. If something else in the workspace still depends on that stored secret — an inbound webhook signed with it, for instance — the whole removal is refused rather than half-done, and the connection survives intact. You get an explanation rather than a broken integration.

Disconnecting does not remove anything you already imported. Tickets and articles brought across by a migration stay where they are; undoing an import is a separate action on the Migrate surface.

What about OAuth?

Several products in the wider catalogue describe themselves as OAuth connections — Help Scout, Salesforce, Slack, Microsoft Teams, Notion, Confluence, Google Sheets, Gmail. No OAuth flow is implemented for any of them, and this route refuses them outright rather than storing something that would never work.

Only Zendesk has an OAuth flow in the product at all, and whether it is offered depends on the deployment: where the client credentials are not configured, the API-token path above is not a fallback but the main road. Freshdesk has no OAuth at all, permanently — a card offering to sign in would be inventing a vendor feature.

If you reach a form that tells you a product uses OAuth and offers no submit button, that is not a bug in your browser.

Connectors that store without testing

A small number of catalogue entries are unfinished connectors. Reached through the API rather than the store, their credentials are stored without being probed, and the row sits at Pending rather than Connected.

Pending means precisely that: we hold a credential and have never found out whether it works. Do not read it as a slow Connected.

Next

• Integrations — the catalogue, the directory and what a connection is.
• Members and roles — the admin floor these actions sit above.