API Key in Headers vs Credentials

Beginner Questions
1

:bullseye: What is your goal?

Hi! Quick question — is there any real difference between adding the API key directly in the HTTP module headers vs using the credentials section to store it?

In my case, the API key expires after a few hours and needs to be refreshed regularly, so I’m wondering if one approach works better than the other for handling that kind of setup.

3

Hey Marc,

how many people are using this workspace and how much of a hassle is it to change it?

4

Hey Stoyan thanks for the quick reply!

Hey! In my case it’s just me using the workspace, so updating it isn’t a big hassle.

The tricky part is that the API token isn’t static. I first need to make an HTTP call with a username and password to retrieve the token, and it’s only valid for about 60 minutes. After that, I need to repeat the process to get a new one.

Given that I have to go through this process every time (even though the integration will only run once per day), I’m wondering if the best approach is to first make an HTTP POST to get the token, and then a second HTTP call to the API I need, passing the token in the headers.

Or is there a more “secure” or recommended way to handle this — especially thinking ahead, since even though it’s just me now, more users might use this in the future? I’d prefer to avoid putting the token directly in the headers if there’s a better practice.

5

The problem is with API key creation; you need to check the provider’s website to see whether you can generate an API key that lasts longer than this. Most providers allow you to create API keys with either a 90-day expiration or no expiration date.

6

Hello,

One of possible solution is to create a separate scenario that generates the token and stores it encrypted in a database.

Here’s how I would handle it:

The main scenario checks the token’s expiration time in the database:

  1. If the token is valid – proceed with execution.
  2. If the token is invalid – trigger a subscenario that:
    1. Makes an HTTP call with username and password (Basic Auth)
    2. Encodes the token using AES via Make’s Encryptor app
      Zrzut ekranu 2026-05-1 o 03.25.03
      Zrzut ekranu 2026-05-1 o 03.25.032384×1020 195 KB
    3. Stores the encrypted token in a Data Store
  3. The main scenario always reads the API key from the database right after validating it’s expiration

There’s also a second approach – cleaner and more scalable, but it requires a bit more experience.
There’s a dedicated API endpoint to manage connections:

In this case, the Data Store only needs to hold the expiration time.

When the token expires, a subscenario updates the API key directly in the connection so HTTP module will use it immediately.

And if you’re on a Pro plan or above, you can use a team/account variable instead to store expiration time.

Have a nice day,
Michal

7

Hi,

Thanks for your message.

I’ve checked with the developers, and since the provider is a banking platform, API keys are required to have an expiration time for security reasons. Unfortunately, this means it’s not possible to create a key with a longer duration or no expiration.

Thanks for taking a look at this.

Have a nice day,
Marc

8

Hi Michal,

Unfortunately, I’m only on the Core plan at the moment, so the second option—which is the best one—isn’t going to be a fit for me right now. I’ll keep it in mind in case I upgrade the plan.

I’ve done some tests with the first option, and for now it’s the one I’m going to use.

Thanks for all your help.

Have a nice day,
Marc