Best Practice for Securely Storing API Keys (e.g. for SMS Service) Without Additional Operations

How To
,
1

Hi everyone,

I’m using a third-party SMS service that requires an API key to be included in the request body. Currently, I see two options in Make:

  1. Store the key directly in each scenario
  2. Use an Organization Variable

However, both approaches seem to lack proper security for storing sensitive credentials like API keys — especially since the variable values are visible to anyone with scenario edit access.

Can you recommend a secure and reliable method to store and use sensitive keys (such as API keys) within Make, ideally without adding extra steps or external tools?

Thanks in advance!

2

Assuming that there’s no existing app in Make for your third-party SMS service, use the HTTP app Make an API Key Auth request module.

When you Add a new keychain the API key you enter will be securely stored in the Make Connection object and can be reused in any other scenario.

image
image557×622 36.1 KB

1 Like
3

Hi,
As I mentioned earlier, I need to include an API key in the request body.
So unfortunately, your solution doesn’t work for my case.
Thank you very much for your response!

4

You’re right - the HTTP app only allows for API Keys in the header or querystring.

It’s unusual to see API Keys passed in the body … but it’s possible that the HTTP app could be extended to allow that.

Could you provide a link to the API reference of the SMS service you’re aiming to use?

5

Hi David,
Thank you very much for your quick reply.
Here is the link to the API documentation: API_UserGuide.latest.pdf

Regards,

6

Thanks for that. I can see that it’s not actually requiring an API key in the body, but instead a username and password.

That’s most definitely not best practice from a security point of view. You might want to consider switching to an alternative SMS service (options here).

7

Hi David,
The “password” field is actually used for an API key.
I agree that this isn’t a particularly secure approach, but my client prefers to work with this service provider for a couple of reasons (e.g., Hebrew language support and pricing), so switching providers isn’t an option at the moment.

Anyway, thanks a lot for your help.
Best regards,