# Best practice for an API key **URL:** \ **Category:** Maker\ **Created:** [June 26, 2020, 2:00pm UTC](https://forum.inductiveautomation.com/t/best-practice-for-an-api-key/36088 "2020-06-26T14:00:13Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [June 26, 2020, 4:34pm UTC](https://forum.inductiveautomation.com/t/best-practice-for-an-api-key/36088/5 "2020-06-26T16:34:38Z")
Some previous discussion around this in this thread: > [@Good way to make sure my gateway scripts only run on the server?](http://forum.inductiveautomation.com/t/good-way-to-make-sure-my-gateway-scripts-only-run-on-the-server/33777): > > More of a design question than anything. I have gateway scripts, some of which involve emailing our companies clients. On occasion, I’ve had coworkers unknowingly backup the gateway to a development machine with an old database copy, and then all of a sudden our clients are getting emails with outdated information that they already received. Not great. Currently I’ve been telling people to not export/import gateway scripts, but there are other scripts that don’t involve emails that are essen… In general, the most important thing is to limit the scope of where you secret can possibly be read from. There's some filesystem based suggestions in that thread that are good practice. Environment variables _can_ work, but aren't guaranteed to be as isolated as you might like them to be, as @pturmel points out in that thread. Ideally, anything interacting with an API would eventually become an Ignition module - in that case, you can store them encrypted & salted in the internal DB, which is a nice bonus. --- _[View the full topic](https://forum.inductiveautomation.com/t/best-practice-for-an-api-key/36088)._