Creating a Ticket in Freshdesk

Freshdesk creates tickets three ways: an agent typing one, an email arriving, or an API call. They produce subtly different tickets, and that matters for reporting.

Start free trial All guides

Create a Freshdesk ticket in the agent interface

From the tickets list there is a new ticket control. The form asks for a requester, a subject, a description, and then the routing fields: status, priority, group, agent, type, and whatever custom fields your account defines.

The requester field is the one that decides everything downstream. Start typing an email address and Freshdesk matches an existing contact. Take the match if it offers one. Typing a fresh address that differs by a plus tag or a capital letter creates a second contact, and now that customer has their history split across two records forever.

Two habits worth building. Write the subject as the customer would recognise it, because it becomes the email subject line they see. And set the group, not the individual agent, so the ticket is visible to everyone who can help rather than parked on a person who might be on leave.

There is also a phone ticket flow, which is the same form framed for a call you are taking now. Same object underneath.

Tickets created from email

This is where most tickets come from and it is worth understanding as a creation path rather than as background magic.

Mail arriving at your connected support address becomes a ticket. The sender becomes the requester, creating a contact if one doesn't exist. The subject becomes the subject and the body becomes the description. Anyone in the To or CC lines can end up attached to the ticket depending on your settings.

The important behaviour is threading. Replies are matched back to the existing ticket by identifiers in the mail headers. When threading breaks, and it breaks over changed from addresses, mangled headers or a customer starting a fresh message instead of replying, you get a second ticket for the same conversation. That is the largest single source of duplicates in most Freshdesk accounts.

Forwarding is the other quirk. When an agent forwards a customer email into the helpdesk, the naive result is a ticket whose requester is the agent. Freshdesk has handling for this so the original sender becomes the requester, and it's worth testing on your own account rather than assuming which way yours behaves.

Creating by API

A POST to /api/v2/tickets with a JSON body. Fields go at the top level, not wrapped in a ticket object.

{"email": "sam@example.com", "subject": "Card declined", "description": "<p>Payment failed twice.</p>", "status": 2, "priority": 2}

What is genuinely required is narrower than the form suggests.

A requester identifier. One of email, requester_id, phone, or a social identifier. This isn't optional. A ticket with nobody attached is not a thing Freshdesk will make.

Status and priority, as integers. 2 is Open, 3 Pending, 4 Resolved, 5 Closed. Priority runs 1 Low to 4 Urgent.

Subject and description in practice, even where the reference is permissive, because a ticket without them is unusable for your agents.

The description is HTML. Send description_text if you want to supply plain text and let Freshdesk handle the markup. Sending raw newlines in the HTML field produces a wall of unbroken text, which is a small thing that makes an integration look broken.

Optional but worth setting on every programmatic ticket: source, so your reporting can tell API-created tickets from email ones, group_id for routing, tags for filtering later, and custom_fields for your own attributes. Get the custom field machine names from /api/v2/ticket_fields rather than guessing, as described in the tickets API guide.

Creating on behalf of a requester

This is the case people get subtly wrong, and it shows up months later as bad data.

A ticket raised by an agent for a customer should have the customer as the requester and the agent merely as the person who created it. If you set the requester to the agent, or let an integration authenticate as an agent and default to itself, then the customer never receives notifications, their ticket history is empty, and every satisfaction survey goes to your own team.

Over the API, that means always passing the customer email or requester_id explicitly. Over the interface, it means using the requester field properly rather than raising the ticket and adding the customer as a CC afterwards.

If the contact does not exist yet, supplying an email creates one. Supply the name as well when you have it, because a contact record that's just an address is a contact nobody will ever recognise in a report.

For internal work with no real customer, resist the urge to invent a placeholder requester. Use a ticket type or a dedicated group instead so those items can be excluded from support metrics cleanly.

The duplicate that creation itself causes

Every one of these paths can produce the same conversation twice.

A customer emails and also fills in the portal form. An agent takes a call, raises a ticket, and the customer emails a confirmation an hour later. An integration retries a create after a timeout and gets two tickets, because a POST that timed out may well have succeeded.

That last one is worth designing against. Keep an idempotency key of your own, a unique reference in a custom field, and check for it before creating. The API won't deduplicate for you.

FAQ

Frequently asked questions

How do you raise a ticket on behalf of a customer?

Use the new ticket form and set the requester to them. Freshdesk create ticket on behalf of customer this way keeps the notification going to the right person, which is the only difference from any other Freshdesk new ticket. Freshdesk raise ticket and Freshdesk add ticket describe the same action.

What fields are required to create a Freshdesk ticket?

A requester identifier such as email or requester_id, plus status and priority as integers. Subject and description are needed in practice for the ticket to be usable.

How do I create a ticket for a customer as an agent?

Set the requester to the customer, not yourself. Over the API pass their email or requester_id explicitly. Getting this wrong sends every notification and survey to your own team.

What are the Freshdesk status values in the API?

Integers: 2 for Open, 3 Pending, 4 Resolved, 5 Closed. Custom statuses have their own numbers, so read them from the API rather than hardcoding a list.

Can I create a ticket with an attachment?

Yes, but that request goes as multipart form data rather than JSON, which means a separate code path in your client from every other call.

Why did my API create produce two tickets?

Usually a retry after a timeout, where the first POST actually succeeded. Add your own idempotency reference in a custom field and check for it before creating.