Skip to content
AscendCore
🔌 Integration Guide

Freshdesk Integration

Keep Freshdesk as your system of record. AscendCore becomes the approval-gated system of action on top: tickets flow in, a human approves in Slack or Teams, the runbook executes, and the decision is written back to the ticket as a private note. No migration.

In one sentence

A Freshdesk Automations rule POSTs new tickets to AscendCore, where the ticket is AI-classified into a runbook, held for explicit human approval, executed against your identity stack, and the outcome lands back on the originating ticket as a private note with an audit-chain reference.

Freshdesk and Freshservice are separate Freshworks products with separate accounts. This guide is for Freshdesk (yourcompany.freshdesk.com). If your service desk runs on Freshservice, use the Freshservice guide instead.

How a ticket flows

  1. Ingest. Your Automations rule POSTs the ticket number to POST /api/v1/tickets/ingest with a scoped API key. AscendCore then reads the ticket's subject, description, and requester from your Freshdesk with the key you connected. One ticket is ingested at most once: retries and rule re-fires return the original run instead of posting a second card.
  2. Classify. AscendCore classifies the ticket text into a runbook intent with a confidence score. Low-confidence or unrecognized tickets are received, audit-logged, and left alone (no_action). Nothing executes on a guess.
  3. Approve. The matching runbook's approval is staged where your organization's approval routing says: a card in your Slack or Teams admin channel, with the originating ticket number, a link back to it, and the AI's classification and confidence; or the approval queue in the admin portal, with approvers emailed. A human approves or denies. Every runbook is approval-gated. There is no autonomous path.
  4. Execute. On approval, the runbook runs against your stack (Okta, Entra ID, M365) and the action is recorded on the org's tamper-evident SHA-256 audit chain.
  5. Write back. The decision (approved or denied, by whom, at what time) is added to the originating ticket as a private note. Your helpdesk keeps the complete story.

Step 1: Connect Freshdesk

In the admin portal under Integrations, open Freshdesk and enter:

Save & verify stores the key in your organization's encrypted vault and reads one ticket to prove the key works. The key is never shown again, and it is used only for your organization. Adding a note is not tested by Verify, because that would change a ticket.

Step 2: Create a scoped AscendCore API key

In the admin portal under API & Webhooks, create a key with only the ticket:ingest scope. The form ticks audit:read and runbook:read by default, so untick them first. The key is shown once, so have the Freshdesk rule open before you create it. A key with only this scope can submit tickets but cannot execute runbooks directly, read audit rows, or browse the catalog.

You will paste this key into the rule's webhook headers in the next step. It is stored inside the rule, visible only to Freshdesk admins who can edit automations.

Step 3: Add the Automations rule

In Admin, then Workflows, then Automations, open the Ticket Creation tab and create a new rule:

{
  "source": "freshdesk",
  "ticket": {
    "ticketId": "{{ticket.id}}"
  }
}

Only the ticket number is sent. Placeholder values are inserted into the body as they are, so a quote or a line break in a subject or description could make the body invalid JSON. AscendCore reads those fields from your Freshdesk instead, which also means a request can only refer to a ticket that exists in your account. Raise a test ticket to confirm a 200 before relying on the rule.

Payload reference

FieldRequiredPurpose
sourceYesMust be "freshdesk" for this integration.
ticket.ticketIdYesTicket number (string or number, #42 is accepted). Idempotency key and write-back target.
ticket.subjectOnly without a connectionPrimary classification input. Read from Freshdesk when it is connected.
ticket.descriptionNoAppended to the classification input. Read from Freshdesk when it is connected.
ticket.urlNoLink back to the ticket, shown to the approver. Built from your connected address when Freshdesk is connected.
ticket.requesterEmailNoTarget-user fallback when the ticket text names nobody else. Read from Freshdesk when it is connected.

The supported intents are the same as for every ticket source; see the Freshservice guide for the current list. Tickets that classify to anything else are acknowledged with no_action and audit-logged.

What the write-back looks like

When the approval reaches a decision (from Slack, Teams, or the dashboard), AscendCore adds a private note to the originating ticket:

[AscendCore] Runbook decision: APPROVED
Runbook: Account Unlock
Target user: Sarah Chen (sarah.chen@acme.com)
Decision by: teams:approver@acme.com at 2026-10-27T15:42:11.310Z
Completed. The action ran after explicit human approval.
AscendCore run: unlock_1793115731_310000
This decision is recorded on the org's tamper-evident audit chain in AscendCore.

Denied requests get a note too, stating that no changes were made. If the run only partly finished, was stopped by a safety check, or failed, the note says so; it never claims an action that did not run. The note is private (visible to agents, not the requester). The write-back is deliberately non-blocking: if Freshdesk is unreachable, the approval flow itself is unaffected and the decision remains on the AscendCore audit chain.

Limits and troubleshooting

Security model

Full API reference

The complete request/response contract for POST /api/v1/tickets/ingest lives in the OpenAPI reference.