Sending credential in query path (Fio bank API)

Questions
1

Describe the problem/error/question

I am building an automation for an endpoint that stores credentials in its query path, like this: https://fioapi.fio.cz/v1/rest/periods/{API_KEY}/2026-05-01/2026-05-12/transactions.json
Is there a way to input a saved credential in the PATH? not as query string parameter at the end, but in the middle of it. ideally by referencing it, like https://fioapi.fio.cz/v1/rest/periods/{$credentials.value}/2026-05-01/2026-05-12/transactions.json
But there is no native option.
Also, using a custom auth and using the qs option is not working, because that adds it as query parameters at the end

Information on your n8n setup

  • n8n version: 2.4.8
  • Database (default: SQLite): sqlite
  • n8n EXECUTIONS_PROCESS setting (default: own, main): own, main
  • Running n8n via (Docker, npm, n8n cloud, desktop app): docker
  • Operating system: Macbook Air Tahoe 26.4.1 (25E253)
3

You can do this by switching the URL field to Expression mode and injecting the credential or env value directly into the path.

Example:
https://fioapi.fio.cz/v1/rest/periods/{{$env.FIO_API_KEY}}/2026-05-01/2026-05-12/transactions.json

OR

https://fioapi.fio.cz/v1/rest/periods/{{$credentials.apiKey}}/2026-05-01/2026-05-12/transactions.json

qs won’t work for this because Fio requires the token inside the URL path itself, not appended as query parameters.

4

Hi, I don’t think n8n lets you directly reference a saved credential value inside the middle of the URL path from the HTTP Request node. Since you are running n8n in Docker, you can pass it as an environment variable and avoid hardcoding the token in the workflow.

If you need stronger credential handling, the cleaner long-term option would be a small custom node or custom credential implementation for this Fio API, because the API design puts the secret in the path rather than in a standard auth location.

5

Can you try this? @Jozin_Cambora

Set your API key as a Docker environment variable and reference it:

In your docker-compose.yml or docker run command:

environment:
  - FIO_API_KEY=your_actual_key_here

In the URL expression field:

https://fioapi.fio.cz/v1/rest/periods/{{$env.FIO_API_KEY}}/2026-05-01/2026-05-12/transactions.json
6

Hey @Jozin_Cambora, welcome! This is a really specific but totally solvable problem.

Building on what @tamy.santos and @kjooleng mentioned, here’s the most practical approach for the Fio API pattern:

Option 1: Use $env variable directly in the URL expression (my recommendation)

In your HTTP Request node URL field, click the expression toggle and write:

https://fioapi.fio.cz/v1/rest/periods/{{ $env.FIO_API_TOKEN }}/{{ $json.dateFrom }}/{{ $json.dateTo }}/transactions.json

Then in your Docker compose, just add:

environment:
  FIO_API_TOKEN: your_actual_token_here

The key thing here is that the URL field in HTTP Request node fully supports expressions, so you can interpolate the token directly into any part of the URL path. This is cleaner than using a Set node.

Option 2: Store token in a Set node upstream

If you don’t want to use env vars, store the token in a Set node first, then reference it:

https://fioapi.fio.cz/v1/rest/periods/{{ $('Set Token').item.json.fioToken }}/....

Both approaches avoid hardcoding the token while keeping it out of query string. The $env approach is cleaner for production.

7

Thank you @nguyenthieutoan and @tamy.santos(and others, I cannot mention the rest for some reason) for the answers, mostly I see that I should create a env variable on my docker instance and use it.
In that case, will the API key be visible in the run history? It would be possible to retrieve it simply by exposing the env variable, right? That is not ideal :face_with_diagonal_mouth:
I guess I would have to really create a custom node + custom credential for this.

8

Choose this if UI masking is what you desired.

You can also consider upgrading to a newer n8n version (2.19+) as it has improved execution data controls and security audits

9

@Jozin_Cambora That’s a really important security question and you’re right to think carefully about it!

To clarify: when you use an environment variable like $env.FIO_API_KEY in an expression (for example, in the URL or query parameters of an HTTP Request node), the value of that variable will appear in the execution history in the input/output data of the node. So yes, anyone with access to the n8n execution logs could technically see the resolved value.

This is the core limitation with env variables vs. proper credentials:

  • Env variables: Convenient, but values are visible in execution data
  • n8n Credentials (custom credential type): The value is masked in the UI and not stored in execution logs by default, which is the proper secure approach

So @kjooleng is spot on. If you want the API key to be truly masked and not appear in execution history, a custom credential type is the right path. It’s a bit more work to set up but it’s the proper production-grade approach for sensitive tokens.

For the Fio bank API specifically, since it uses a simple token in the URL query string, you’d create a custom credential that stores the token, then reference it in your HTTP Request via the credential. n8n will mask it in the logs.

If you’d like help with the structure for a custom credential definition for this use case, happy to share a template. It’s not as complex as it sounds once you see the pattern!