The queue of tickets where the support team owes the customer a reply.

This is the entry point for "what do I have to answer". It does NOT trust ticket status: a ticket can sit in a custom status like "In Progress" and still owe an answer. Instead it compares, per ticket, when we last replied against when the customer last wrote. Tickets waiting on the customer are excluded, as are terminal ones.

Ordered by how recently the customer wrote, so entry #1 is the freshest thing left unanswered. Read the full thread with freshdesk_get_ticket and freshdesk_get_conversations before drafting anything.

List tickets by recent activity, optionally filtered by status.

Statuses are given by NAME or code and validated against this account, so you cannot silently filter on a status that does not exist. Leave "statuses" empty to get every non-terminal status.

This answers "what is going on"; for "what do I owe an answer on", use freshdesk_find_unanswered_tickets instead — reply state is not derivable from status.

Full detail for a single ticket: fields, requester, company and reply timestamps.

The description is the customer's ORIGINAL request, converted from Freshdesk's email HTML to markdown. It is not the latest message — use freshdesk_get_conversations for the thread.

Freshdesk's filter/search endpoint, for questions a plain listing cannot express.

Query syntax: "status:3 AND priority:4", quote strings ("tag:'billing'"), dates as YYYY-MM-DD with :> and :< (>= and <=). Supported fields: agent_id, group_id, priority, status, tag, type, due_by, fr_due_by, created_at, updated_at, closed_at, plus custom fields by their cf_ name.

Hard limits from the API, not from this server: the query is capped at 512 characters, results come 30 per page, and only 10 pages are reachable — 300 results maximum. Archived tickets are excluded.

The real field inventory of this Freshdesk account: every status with its code and label, priorities, sources, ticket types, and every custom field with its choices.

Worth reading before filtering or writing. Accounts define their own statuses, so the Freshdesk defaults (2=Open, 3=Pending) are often nearly unused, and a filter built on them returns nothing while looking correct.

Every message on a ticket, oldest first, each one labelled with who wrote it and who can see it:

CUSTOMER — the requester wrote it AGENT (public) — we wrote it and the customer received it AGENT (private) — an internal note; the customer never saw this

Two things to know before drafting from this. The ticket DESCRIPTION is the customer's first message and is not part of this list — get it from freshdesk_get_ticket. And many tickets open with an automated private note from the helpdesk itself: that is internal routing chatter, not something the customer said.

The person behind a ticket: name, email, job title, company and any custom contact fields. Use the requester_id from a ticket.

The account a contact belongs to, with its notes and custom fields. Useful for tone and for knowing how much a ticket matters.

Every recent ticket from the same person — the answer to "have they asked this before?".

Read this before drafting anything that explains a known issue: if the same requester already got an answer three weeks ago, repeating it differently is worse than pointing back at it.

The tickets Freshdesk links to this one: children of a parent ticket, or the tickets tracked by a tracker.

This is how a recurring incident shows up as one thing instead of nine: if a ticket is tracked, the answer probably belongs on the tracker.

The wording the team already approved, by folder.

Reach for this before inventing a phrasing: a canned response carries the tone, the legal caveats and the escalation wording someone already decided on. Pass a folder_id to list its responses, or omit it to see the folders.

The full body of a canned response, as markdown. Freshdesk placeholders such as {{ticket.requester.name}} are left untouched — substitute them yourself before sending.

Search published solution articles by keyword, so a reply can point at the documented answer instead of paraphrasing it.

Freshdesk has no article search endpoint in the v2 API, so this walks the category/folder tree and matches titles and bodies locally. That costs several calls against the rate limit, so it caches nothing and is worth calling with a narrow term.

The full body of a solution article, as markdown.

Move a ticket: status, priority, assignee, group, type, tags, custom fields.

The customer is not emailed by this, but changing status IS visible to them on the portal, and Freshdesk automations may react to it.

Statuses and priorities are accepted by name or code and validated against this account first, so a wrong value fails here — listing the valid ones — instead of coming back as an opaque 400.

Add a private note to a ticket. THE CUSTOMER NEVER SEES THIS and no email is sent.

This is where a draft reply belongs. Freshdesk has no draft concept in its API, but a private note is exactly that: the text sits on the ticket for a human to read, edit and send themselves. Prefer this over freshdesk_reply_to_customer whenever a person should approve the wording first.

Accepts markdown or plain text and converts it to the HTML Freshdesk expects, so line breaks survive.

Add a note the requester CAN see on the support portal. Freshdesk does not email a public note, so it is quieter than a reply — but it is still customer-visible and cannot be unsent.

If you want the customer to actually receive the message, use freshdesk_reply_to_customer. If a human should approve it first, use freshdesk_add_private_note.

Send a public reply on a ticket. THIS EMAILS THE REQUESTER and cannot be unsent.

Two-step by design: called without confirm, it returns exactly what would be sent — recipients, subject line, rendered HTML — and sends nothing. Call it again with confirm: true to actually send. A retry or a mistaken tool call therefore costs a preview, not an email to somebody's customer.

If a human is supposed to approve the wording, do not use this at all: put the draft in freshdesk_add_private_note and let them send it.

Record a time entry against a ticket. Internal bookkeeping: the customer never sees it.