Critical security update to the platform - May 2021

Dear Freshworks App Developers,

We hope this update finds you in health and safety.

We relish every moment of working along with app developers like you and conduct our practices in ways you will appreciate. Our team is simultaneously vigilant of security aspects that are of utmost priority to us as a platform and the users of your apps.

Our team has recently become aware of an issue that affects the security posture of our platform. As we take the necessary steps to address our security posture, this may require your attention for apps that are currently live in a customer’s instance. The specific risks we are trying to cover involve an agent gaining unauthorized access as an administrator within a Freshworks product.

As the very first step, until further notice, we have decided to temporarily suspend access to a few admin-specific API endpoints from the Request Method (regardless of app type) effective immediately.

Please find the list of API endpoints suspended temporarily.

To further elaborate the restriction, these API endpoints will only be restricted under the following conditions:

  1. The app uses the Request Method to make API calls to the endpoints outlined.
  2. The app uses an associated HTTP method for the affected endpoints, as captured in the list.
  3. API requests are made via the Request Method from the app frontend.
  4. API calls are made via the Request Method from the app backend with the static IP parameter set to true.

Based on our analysis, we expect very few apps are likely to rely on these endpoints. In case you find your app consuming any of these APIs via the Request Method, please get in touch with us at We will watch out for your requests to get you the necessary support as soon as possible.

In case your team identifies itself as a Freshworks developer partner, please also consider seeking assistance from Program Managers from Freshworks closest to your team.

You can read further on this topic through a Wiki article we recently added and comment to call out anything we may have missed addressing.

We would rarely want to take such drastic measures without notice, but unfortunately, our team felt this situation calls for it, in order to protect the interests of both you as a trusted developer and the customers that trust your work on our platform. We apologize for any inconvenience this may have caused and thank you for your support in making our platform more secure.


19 May 2021 :thread: Read Complete Annoucement

24 May 2021

Over the last few days, we have rolled out a couple of urgent updates to our platform to significantly enhance our security posture with respect to how installation parameters are used. First, we took steps to minimize the surface area of the impact. Next, we rolled out another update to how the Request Method on our platform can use secure installation parameters.

Our next planned update on this front is to start mandating that any domain that a Request Method makes a request to must be defined in the whitelisted-domains property of the app manifest. Our latest Freshworks CLI release v6.11.0 already enforces this.

Starting 4 June 2021, apps uploaded to the platform - either as a custom app or a public app - will be expected to whitelist any domain it wishes to make requests to via the Request Method. This change will currently not affect apps that were already deployed earlier than 4 June, and they will continue to work without a defined whitelist for now. We will share another update shortly for how your already deployed apps can comply with this requirement as well.


Hello @Saif,

Would it be possible to provide an example of what the iparams should look like moving forward? Maybe something basic like Freshworks product Domain and API key. The two most commonly used iparams for applications. And also a valid example of how to get requester or contact information based on using the request method and passing in the secure iparam in the headers property. Might be good to add as a wiki perhaps. Just a suggestion. :slight_smile:



Hi @Saif

Adding to @Zach’s question.

How would we know at compile-time what the value of Domain must be?
If we are expecting the customer to provide the Domain, we could not possibly include that in the manifest.json file under whitelisted-domains.

Shedding more light on this with an example would help.


1 Like

@arunrajkumar235, @Zach

you can use wildcard or template literal to specify the whitelisted-domains


"whitelisted-domains": [


"whitelisted-domains": [
    "https://<%= iparam.domain %>"

the template literal is based on how you define the domain

Hope it helps



Thanks for that update @Santhosh.

It would greatly help the developer community if wildcards and template literals were also documented in the official documentation.


The issue is, that when you want to test it locally it won’t accept it. Since it has to be https & not localhost domains.

How is it possible to test locally now?

1 Like


Very valid question. Thanks for asking.

I request you to use 3rd party services like ngrok which will help create a public URL out of localhost over https protocol. This way, Freshworks CLI will recognize the URL and make API calls.

Please feel free to create a new topic on the forum if you need further help.


We discussed this internally and decided that developers should be able to make API calls to http://localhost URLs using the request method when simulating the app.

In the latest release FDK v6.13.2

  • CLI will not throw an error if you use client.request.METHOD(..) to make API calls to http://localhost URLs.
  • However, fdk validate / fdk pack will throw an error. This is to ensure the developer has reminded this an exception for only development purposes.

Thank you @JonathanHojtoft, for asking this question. This has influenced the product for everyone who uses fdk.