Use request method to place secure HTTP calls

Request method is a secure mechanism to send HTTP requests from an app to a third-party domain, without exposing any sensitive information that is part of the request. Through browsers, app users may intercept sensitive information such as API keys or user credentials. Request method safeguards against such exposure. Typically, HTTP requests are routed through proxy servers. In such cases, sending the HTTP requests through the request method helps identify the origin in scenarios where the third-party domain has enabled Cross Origin Resource Sharing (CORS) support.

To use the request method,

1. As part of the app configuration, configure request templates.
2. In manifest.json, declare the template(s) that the app code uses.
3. From the app logic, invoke the configured template(s), and make HTTP requests to third-party domains.

At times, API/resource providers do not want apps to connect to their APIs/resources, unless the app is trying to connect from a known and approved system/org. To get the origin (from where the requests originate) approved, the app devs will have to provide the list of IPs from which the requests can originate. The resource providers will allow-list these IPs in their system and allow any request that comes from these IPs to access their resources. If you want to access such a resource, you will have to provide the following IPs to the resource providers, for allow-listing.

For custom app devsIf you are building an app and if IP whitelisting is enabled for the parent application (the Freshworks' product on which the app is deployed after installation) account, allow-list the following IPs to enable your app to access the parent application resources.

Request templates are snapshots of all the HTTP requests that an app is expected to make.

1. From the app’s root directory, navigate to the config folder and create a requests.json file (if requests.json does not exist).
2. In requests.json, use the following syntax to configure all request templates that the app is expected to use, as JSON objects.

Template substitutions enable the usage of variables in the <requestTemplateName>.schema attributes. During runtime, depending on where the variables are used, they can be populated by:

• Installation parameter (iparam) values
• Contextual data
• currentHost - endpoint_urls
• Stored access tokens
• App settings

Variables can be used only in the following <requestTemplateName>.schema attributes. Also, the type of data that can populate the variables varies depending on the attribute in which the variables are used.

Use the following syntax to declare a template variable that is populated with iparam values at runtime.

<%= iparam.validIparamName %>

variableName must match the context variable name used in the runtime API when invoking the request template. If there is a mismatch in the names, the runtime API call fails.

encode() This function enables encoding secure iparams that are passed as part of the request.

Use the following syntax to declare a template variable that is populated with contextual data, passed through the runtime API that invokes the request template.

<%= context.variableName %>

Important:To construct a dynamic host value that is populated during runtime, though it is possible to retrieve the endpoint_urls through the currentHost data method or from the serverless payload attributes and pass it as contextual data, you should use the currentHost - enpoint_urls template substitution method. For more information on currentHost and endpoint_urls, see Global app concepts.

Use the following syntax to declare a template variable that is populated, at runtime, with the appropriate url of the account (product) on which the app is deployed.

<%= current_host.endpoint_urls.<product_name> %>

Note:During local testing, you can navigate to the System settings page and enter the account URLs that are necessary to test your app. At times, a module can apply to two products. For example, deal is one such module that applies to Freshsales Classic and Freshsales Suite. In this case, the <product_name> in the <%= current_host.endpoint_urls.<product_name> %> syntax helps to place the API call to the appropriate product resource, during local testing.

Use the following syntax to declare a template variable that is populated with an access token value.

<%= access_token %>

Note:This variable is used only in <requestTemplateName>.schema.headers.<header_value> to facilitate the app to place an OAuth request call. This variable should be used when <requestTemplateName>.options.oauth is set to the name of the OAuth configuration object defined in the config/oauth_config.json file.

Use the following syntax to declare a template variable that is populated with the app settings values at runtime.

<%= app_settings.{key} %>

From templates configured in the config/requests.json, in manifest.json, declare the ones that the app code uses, for a specific product.

1. From the app’s root directory, navigate to the manifest.json file.
2. Under modules.common, use the sample shown in the right pane and create a requests attribute.

To send an HTTP request to a third-party domain, in the app code, include the invokeTemplate() method. This method serves as a runtime API call. As part of the call, the app can pass a dynamic context and any other data that the template requires.

• requestTemplateName string Mandatory
  Identifier of the request template in config/requests.json and the request in manifest.json. The requestTemplateName must be the same in the app code, configuration (config/requests.json), and declaration (manifest.json).

• An object with the following optional attributes:

  • contextobject

    All contextual data that the template requires, specified as key-value pairs of <variableName>:<variableValue>. <variableName> must be the same as that used in config/requests.json to receive contextual data.

  • bodyobject

    Request body.
    
    Response caching: Requests made through the request method are governed by rate limits. To prevent repetitive calls from breaching the rate limits, the request method comes with an opt-in response caching feature, for front-end apps. The cache and ttl options available as part of the invokeTemplate() method, enable browsers to cache the responses that are retrieved from third-party calls. The responses are cached in the Browser’s local storage. For requests that haven’t changed since the last call, the response is retrieved from the cache. This conserves the app’s rate limits as the number of requests made to the third-party are conserved.

    show child attributes

{
"status" : 200,
"headers":
  {
    "Content-Length": 20,
    "Content-Type": "application/json;charset=utf-8"
  },
"response": '{ "Name": "Rachel"}'
}

In the local testing of apps that use the Request Method to make third-party HTTP requests, you can specify a value for the request timeout.

To configure the request timeout to a suitable value, use the fdk config command to set the request timeout as follows.

This command adds or updates the request.timeout attribute with the given value in the .fdk/configs.json file of your app.

For information on how to test an app that uses the Request method feature, see Test your App.