Changing Your Freshdesk URL

Two different jobs hide behind this question, and one of them is far riskier than the other. Work out which you're doing first.

Two ways to change a Freshdesk URL

People asking how to change their Freshdesk URL want one of two things, and conflating them is how afternoons get lost.

Changing the subdomain. Your account lives at something.freshdesk.com. Companies rename, rebrand, get acquired, or somebody typed the trading name wrong during signup. Changing this alters the underlying account address, which is what every integration, every API call and every bookmark points at. This is the risky one.

Adding a custom domain. You keep the underlying account exactly as it is, and point something like support.yourcompany.com at your customer portal using a CNAME record. Customers see your domain. Agents can carry on using whatever they use. This is the low-risk one, and it is what most people actually want.

If your motivation is that customers should not see freshdesk.com in the address bar, you want the custom domain. Read on carefully only if the subdomain itself is genuinely wrong.

The custom domain route

The mechanics are ordinary DNS work. You choose a hostname on a domain you control, commonly support. or help., create a CNAME record pointing to the address Freshworks specifies, and configure the portal to use it.

Three things worth getting right.

SSL. Your portal must serve over HTTPS. Freshworks handles certificates for custom portal domains, but the specifics and any prerequisites are the kind of thing that changes, so follow the current Freshworks documentation rather than assuming.
Propagation. DNS changes aren't instant. Expect it to be live in minutes and allow up to a day before you conclude something is wrong.
Multiple portals. If you run multiple products with separate portals, each needs its own hostname and its own record. Doing one and forgetting the others is the common miss.

This route doesn't change your API base URL and does not affect agent logins, which is exactly why it is the safer option.

What breaks when the subdomain changes

Everything that hardcoded the old address, which is more things than any inventory you write down in advance.

The API base URL. Every script, every integration, every webhook consumer using yourcompany.freshdesk.com/api/v2 is now calling an address that no longer resolves to you. Anything built on the Freshdesk API needs updating.
Marketplace and third-party apps. Each connected system stores your account URL in its configuration. CRM connectors, phone systems, chat tools, reporting tools. Each one is a separate thing to reconfigure.
SSO. Identity provider configuration references your Freshdesk endpoints, and the entity ID or reply URLs typically contain the subdomain. Get this wrong and every agent is locked out simultaneously. Read SSO and security before touching anything, and have a break-glass local admin login ready.
Email routing. Your system address and any forwarding rules pointed at the old domain need checking end to end.
Links in published content. Knowledge base articles that link to other articles by absolute URL, links on your website, links in email templates and canned responses, links in your product, links in old ticket threads customers still have in their inbox.
Bookmarks, saved searches and mobile app configuration for every agent. Trivial individually, disruptive on a Monday morning when nobody can find anything.

Whether the old subdomain redirects, and for how long, is not something to assume. Ask Freshworks support directly and get the answer in writing before you schedule the change.

The checklist

Work through this in order. The sequence is the point.

Before

Confirm with Freshworks support that the change is possible on your account and ask exactly what happens to the old address.
Inventory every integration. Go through installed marketplace apps one by one, and grep your own codebase for the current subdomain string. The codebase search always finds something the inventory missed.
Note your SSO configuration in full, on both sides, including entity IDs and reply URLs.
Create or confirm a local admin account that can log in without SSO, and test that it works.
Pick a genuinely quiet window. Not Monday. Not month end.

During

Make the change, then immediately verify agent login, both SSO and the local account.
Send a test email from an outside address and confirm it becomes a ticket.
Load the customer portal as a logged-out visitor.
Run one API call from each integration and confirm a 200 rather than assuming silence means success.

After

Reconfigure every third-party app with the new URL.
Update email templates, canned responses and published article links.
Tell your agents, with the new address, before they need it.
Watch the ticket queue for 48 hours. A drop in inbound volume means something isn't routing, and that is the failure that hides longest.

The bit people forget

Customers have your old portal URL bookmarked, in their inbox, and in whatever internal wiki their IT team maintains. Some of those links will be followed for years.

If the old address stops resolving without a redirect, those customers hit an error page and conclude your support has disappeared. Some will find you. Others will just be annoyed, and a few will email an address that no longer works and assume they have been ignored.

Mitigate it deliberately. Publish the new address anywhere the old one appeared, and keep the old email path alive as long as you possibly can. Email is the route that fails silently, and silence is the expensive kind of failure.

FAQ

Frequently asked questions

How does a custom domain differ from changing the subdomain?

A Freshdesk custom domain points your own hostname at the Freshdesk portal URL with a Freshdesk CNAME record. Changing the subdomain changes the underlying address itself, which breaks API integrations and SSO.

Can I change my Freshdesk subdomain?

It is not a self-service setting you toggle. Raise it with Freshworks support, confirm what is possible for your account, and specifically ask what happens to the old address and for how long.

What is the difference between a custom domain and changing the subdomain?

A custom domain points your own hostname at the customer portal via CNAME, leaving the underlying account address untouched. Changing the subdomain alters the account address itself, which every integration and API call depends on.

Will a change of Freshdesk URL break my API integrations?

Yes. The account URL is the API base URL. Every script, connector and webhook consumer referencing the old subdomain needs updating. Search your codebase for the old string, do not rely on a list.

Does a custom domain affect SSO or the API?

No. That is the appeal. A custom portal domain changes what customers see and leaves agent login and the API base URL exactly as they were.

How long does DNS take for a custom domain?

Usually minutes, occasionally up to a day. Allow a full day before assuming a misconfiguration, and check the record with a DNS lookup tool rather than by loading the page in a cached browser.

While you are cleaning things up

Duplicate tickets are typically 8% to 20% of a queue. Ticket Merger finds and merges them in Freshdesk automatically, with a 14-day trial and no card.

Start free trial

14-day free trial. No credit card required.