Freshdesk API Documentation
The official Freshdesk API documentation is good. It's also flat, so most people bounce off it. Here's the shape of the thing before you start reading endpoints.
Where the Freshdesk API documentation actually lives
The current reference sits on the Freshdesk developer site, published as a single long API reference for v2 alongside separate sections for apps, the Freshworks Developer Platform and the marketplace SDK. Those are different products solving different problems. Conflating them costs people an afternoon.
The split is worth learning once.
If your job is "sync tickets into our warehouse" or "raise a ticket from our app", you want the first one and can ignore the other two entirely.
The base URL and the one auth pattern
Every call goes to your own domain, not a shared api.freshdesk.com. The shape is https://yourdomain.freshdesk.com/api/v2/<resource>, where yourdomain is whatever precedes .freshdesk.com in your agent URL.
That's a small detail with a large consequence: there's no account identifier in the payload anywhere, because the hostname is the account identifier. Sandbox accounts and separate brands are separate hostnames, so a config file that hardcodes the domain will silently point at the wrong data when someone copies it between environments.
Auth is HTTP basic. You send your API key as the username and literally any string as the password, with X being the convention everyone uses. There's no OAuth dance for the core REST API, no token refresh, no expiry. One long-lived secret does everything that key's owner can do.
Requests that send a body need Content-Type: application/json. Attachments are the exception and go up as multipart/form-data, which trips up people who built the rest of their client around JSON.
The resource families worth knowing
The reference lists a lot of endpoints. In practice integrations touch about six areas.
Settings such as business hours, SLA policies, email configs and product mappings appear too, though coverage is thinner and read-only in more places than you'd like.
Rate limits, and reading them properly
Freshdesk enforces a per-account hourly credit budget rather than a per-second throttle. The exact allowance depends on your plan and it has changed more than once, so take the number from the current reference or from your own response headers rather than from any blog post.
The headers are the reliable source. On each response you get the total allowance, how many calls remain in the current window, and how many credits that particular request consumed. That last one matters, because some calls cost more than one credit. Anything that returns embedded resources tends to be more expensive than the plain version.
When you exhaust the budget you get 429 Too Many Requests with a Retry-After header giving seconds. Honour it. Don't use a fixed sleep, and don't retry immediately, because a hot retry loop burns the next window before it opens.
Build the limiter before you build the feature. Retrofitting backoff into a script that already runs in production is how people end up locked out of their own helpdesk for an hour.
What the documentation does not tell you
Four things you learn by hitting them.
Custom field names in the API aren't the labels you see in the interface. They're machine names, often with a prefix, and they differ per account. Fetch the ticket fields endpoint and map from there, always.
Deleted and spam tickets are excluded from list results by default. If your sync count never quite matches the interface, that's usually why.
Errors come back as a JSON envelope with a code, a message and, for validation failures, a list naming the offending field. Log the whole body. The HTTP status alone rarely tells you which of the eleven fields you sent was wrong.
And plan tier gates real endpoints, not just features. Something documented without a visible plan note may still 403 on a lower tier, so test against the account you'll actually run on.
Frequently asked questions
Where do the Freshdesk API docs actually live?
At developers.freshdesk.com. That Freshdesk API reference is the developer documentation for the Freshdesk REST API, organised by resource, and it doubles as the Freshdesk API guide most people learn from.
What is the Freshdesk API base URL?
Your own account domain plus the version path, in the form https://yourdomain.freshdesk.com/api/v2/. There's no shared API hostname, so the domain is effectively your account identifier.
Does the Freshdesk API use OAuth?
The core REST API uses HTTP basic auth with your API key as the username. OAuth appears in parts of the wider Freshworks developer platform, but for straightforward server-to-server calls you are using basic auth with a long-lived key.
What are the Freshdesk API rate limits?
An hourly credit budget per account that varies by plan and has changed over time. Read the current API reference for the number, and read the rate limit headers on every response for the truth about your own account.
Does the Freshdesk API documentation cover an official SDK?
Freshworks publishes an SDK for building apps that run inside the product. For the REST API most teams use a plain HTTP client in their own language, since basic auth and JSON need very little wrapping.
Can I try API calls without writing code?
Yes. curl or any REST client works, and the auth is simple enough to paste in. Use a sandbox or a test group first, because there's no undo on a bulk update.
What the API cannot fix on its own
Duplicate tickets are typically 8% to 20% of a queue, and finding them by API is a project of its own. Ticket Merger does it automatically on Freshdesk and Zendesk.
Start free trial14-day free trial. No credit card required.