Passing Dynamic Template Variables to request.json for API Key Selection

App Platform
, , , ,
1

Hi everyone,
I need some clarification and assistance regarding dynamic template variables in request.json.

Use Case Overview

I’m trying to fetch Freshdesk tickets based on the logged-in user’s API key.
Here is how the flow works:

  1. Each agent provides their own API key in the app’s Settings (iparams).
  2. All API keys are stored securely in iparams.
  3. I have a toggle button in iparams that controls how the app should fetch tickets:
  • If enabled → fetch tickets using the logged-in user’s API key
  • If disabled → fetch tickets using the admin’s API key

Requirement

To implement this, I need to send a dynamic template variable (context value) when invoking the request template.

This template variable will decide which API key to use inside request.json.

  • When toggle is ON → template variable should provide the user’s API key
  • When toggle is OFF → template variable should provide the admin’s API key

So the value of this template variable changes dynamically based on the toggle state.

Issue

When I try to pass this dynamic template variable while invoking the request template, I receive an error.
(Full code and error message are shared below in my post.)

I want to know:

  • Is there a correct way to pass dynamic template variables to request.json at runtime?
  • Can we conditionally access iparam values inside the request template?
  • What is the recommended approach to switch between two different API keys inside a request template?

Any guidance or examples would be really helpful.

Thanks!

app.js


  try {
         
          const context = { filter: filter + pageOptions };
          if (this.isApiAccessEnabled)
            context.params = "<%= encode(iparam.api_key) %>";
          else {
            context.params =
              "<%= encode(iparam.credentials[context.agentId]) %>";
            context.agentId = this.loggedInUser;
          }
          const { response, status, headers } =
            await this.fdObject.request.invokeTemplate("getAllTickets", {
              context,
            });
          if (status === 200) {
            const tickets = JSON.parse(response);
            return {
              tickets,
              headers,
              error: false,
            };
          }
        } catch (error) {
          console.error(error);
          if (error.status == 400 || error.status == 404) {
            this.showNotify(
              { message: "Invalid API Key / Domain Name" },
              "danger"
            );
          } else if (error.status == 429) {
            this.showNotify(
              { message: "Too many requests. Please try again later." },
              "danger"
            );
          } else {
            this.showNotify({ message: error.response }, "danger");
          }
        }

requests.json

"getAllTickets": {
    "schema": {
      "protocol": "https",
      "method": "GET",
      "host": "<%= iparam.domain %>",
      "path": "/api/v2/search/tickets?<%= context.filter %>",
      "headers": {
        "Authorization": "Basic <%= context.params %>",
        "Content-Type": "application/json"
      }
    }
  }

Error:

image
image564×217 12.5 KB

2

Hi Arokiya,

Firstly, that’s a fantastic approach to solve for the authorization problem that comes with using the Admin’s API token for all API requests.

In the case that you have beautifully explained, it makes total sense to be able to pass variables to the request template so that the appropriate secure iparam can be used to make the request. However, by doing that it would make the request template weaker. In theory, it would be possible to even pass the entire API token via the context object and weaken the security of the request template. I don’t think Freshworks will allow this.

As an alternative, have you considered moving your logic to a Server method? In the server method you have access to all the secure iparams and will be able to use the agent-sepcific API token to make the request.

Regards,
Arun Rajkumar

1 Like
3

Hi @arunrajkumar235 ,

Thanks for the response.

As you mentioned, sending the API key through the context object can lead to security concerns, so I understand why that approach isn’t recommended.

However, I’m still not fully clear about the second approach. How does it work in practice? Since I’m making multiple API calls using different Request Templates, would that mean I need to create a separate SMI for each Request Template? I want to be sure I’m understanding this correctly.

Could you please clarify?

4

You could use a single SMI to handle all your requests. The payload can contain the path of the resource that you want as well as the flag which says whether to use the admin token or the agent’s personal token. You will also need to pass the ID of the agent so that the Server Method can decide the appropriate token to use.

By default all Server Methods get the the entire iparams (including the secure iparams) so it won’t have any issues accessing all the tokens.

I hope this clarifies.

1 Like
5

Okay @arunrajkumar235 , let me try this and get back to you. Thanks for the assistance.

6

Hi @Debjani and @Thakur_Ganeshsingh
I hope you’re doing well.

I have a requirement to make API requests using the logged-in agent’s API key.

Currently, we can fetch an agent’s API key through iparams, but there are a couple of limitations:

  1. Access restriction:
    Only admins can access the iparams configuration page. Non-admin agents cannot configure or manage their API keys, which blocks this approach for us.
  2. Template variable limitation:
    If the admin configures all API keys and we try to dynamically make requests based on the logged-in agent, we need to pass template variables via the context object in the request template. However, this approach does not work as expected.

As a workaround, @arunrajkumar235 suggested making these API requests in server.js using SMI functions, which would allow access to secure iparams. While this technically solves the problem, it significantly increases the complexity of the implementation and adds unnecessary backend dependency for what is essentially an agent-specific request.

Because of this, I’d like to request you and your team to consider this as a feature request:

Allow frontend API requests using the logged-in agent’s API key, without relying on admin-configured iparams or server-side workarounds.

Why use the logged-in agent’s API key?

Each agent in Freshdesk has different scopes and access rights. At the moment, the app platform does not support making API requests with the logged-in agent’s API key. As a result, even if an agent does not have access to certain resources based on their scope, they can still indirectly access them via the admin’s API key used by a custom or marketplace app.

This behavior breaks the concept of agent-level permissions and security, and it doesn’t align with how access control is expected to work within Freshdesk.

Supporting API requests with the logged-in agent’s API key would:

  • Respect agent-level scopes and permissions
  • Improve security and data isolation
  • Reduce unnecessary backend complexity
  • Make custom and marketplace apps more aligned with real-world agent access control

Looking forward to your thoughts on this. Please let me know if you need any additional details or clarifications.

1 Like