# HAPI Key Security **URL:** \ **Category:** HubSpot Ideas\ **Tags:** integrations, account-settings\ **Created:** [February 26, 2019, 4:42am UTC](https://community.hubspot.com/t/hapi-key-security/13230 "2019-02-26T04:42:32Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![gillytech](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/gillytech/32/3850_2.png) [@gillytech](https://community.hubspot.com/u/gillytech)\ **Post date:** [February 26, 2019, 4:42am UTC](https://community.hubspot.com/t/hapi-key-security/13230/1 "2019-02-26T04:42:32Z")
As it stands the HubSpot API will accept the HAPI Key for all requests. As a corollary this means that anyone who has the HAPI Key can do anything with the account. Such as: - Export all contact information - Send any email campaign - Manage users - Export and manage deals - Etc. There is no way to limit the power of the HAPI Key in HubSpot which is really a weak point. If the key is ever compromised, the portal is at extreme risk which can do irreparable damage to a company/brand. What is needed is a more comprehensive security setup for HAPI keys. Yes, we can phase them out and move to OAuth, but seriously, the HAPI Key is used in so many integrations by now that it would be literally impossible to “phase out” at this point. So, for the long run I am proposing: - Create a way to maintain multiple keys and suspend/revoke their access - Make it possible to limit them by IP - Add an optional hashing mechanism for [sensitive] calls - Add a way to fine tune any key’s access to different APIs. As an example, look at [SparkPost’s](https://www.sparkpost.com/) API key management: ![Edit_API_Key___SparkPost-2.jpg](https://d2qpr2jzcazej7.cloudfront.net/original/3X/2/a/2ab725390d99540a3f86e47d4c1935999d4bde50.jpeg) ![API_Keys___SparkPost.jpg](https://d2qpr2jzcazej7.cloudfront.net/original/3X/8/b/8bc9effef61e07edc070fcca66c98475c8497386.jpeg) I would also like to add that the key itself looks like a UUID v4 — [not](https://tools.ietf.org/html/rfc4122#section-6) [guaranteed](https://stackoverflow.com/questions/3652944/how-securely-unguessable-are-guids) [to be](https://littlemaninmyhead.wordpress.com/2015/11/22/cautionary-note-uuids-should-generally-not-be-used-for-authentication-tokens/) [cryptographically secure](https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random)). I think you would be better off using other recommended hashing methods to generate guaranteed unique and unguessable keys at least 128bits long. Just my own two cents. ---
**Author:** ![MarkdeLange](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/markdelange/32/59606_2.png) [@MarkdeLange](https://community.hubspot.com/u/MarkdeLange)\ **Post date:** [March 6, 2019, 12:30pm UTC](https://community.hubspot.com/t/hapi-key-security/13230/2 "2019-03-06T12:30:17Z")
Great idea, I agree the happykey is a weak spot from a security point of view. Another use case is where on a global account individual users may need to be restricted to accessing data via the happykey to assets based on HS teams/brands. ---
**Author:** ![hannuCR](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/hannucr/32/85342_2.png) [@hannuCR](https://community.hubspot.com/u/hannuCR)\ **Post date:** [March 14, 2019, 6:47am UTC](https://community.hubspot.com/t/hapi-key-security/13230/3 "2019-03-14T06:47:20Z")
Yes, this is definitely a necessary feature, please implement this. ---
**Author:** ![gillytech](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/gillytech/32/3850_2.png) [@gillytech](https://community.hubspot.com/u/gillytech)\ **Post date:** [August 4, 2019, 3:56pm UTC](https://community.hubspot.com/t/hapi-key-security/13230/4 "2019-08-04T15:56:26Z")
**SECURITY ADVISORY** As a supporting argument for better API security, and to deter unsuspecting HubSpot users from compromising the security of their accounts, I’d like to point something out. I was on a site called [emaillistverify.com](http://emaillistverify.com). The site offers email verification services which isn’t a bad thing. However, they offer a HubSpot “integration” which **asks for your hapikey** in order to connect. HubSpot offers a standard OAuth authentication structure for legitimate apps. You should NEVER give out your hapikey to any other company or individual on the internet. With this key anyone can do almost anything to your account with reckless abandon. ![emaillistverify.jpg](https://d2qpr2jzcazej7.cloudfront.net/original/2X/0/0ca2a679b711a8ca5f3cbf844675595d42c47a4f.jpeg) To the HubSpot engineers, please help us secure our HubSpot accounts! There needs to be granular access controls and multiple key management. ---
**Author:** ![RiccardoPisani](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/riccardopisani/32/104209_2.png) [@RiccardoPisani](https://community.hubspot.com/u/RiccardoPisani)\ **Post date:** [September 23, 2019, 7:14am UTC](https://community.hubspot.com/t/hapi-key-security/13230/5 "2019-09-23T07:14:08Z")
+ 1 definitely needed - It is imo one of the most important things for a big company and a more structured HS account like the one we have. ---
**Author:** ![Hani-RT](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/hani-rt/32/32563_2.png) [@Hani-RT](https://community.hubspot.com/u/Hani-RT)\ **Post date:** [January 6, 2020, 7:49pm UTC](https://community.hubspot.com/t/hapi-key-security/13230/6 "2020-01-06T19:49:48Z")
Does this feature request also take into consideration the issue mentioned here? [https://community.hubspot.com/t5/HubSpot-Ideas/Allow-more-than-one-active-API-key-at-a-time/idi-p/310166](https://community.hubspot.com/t5/HubSpot-Ideas/Allow-more-than-one-active-API-key-at-a-time/idi-p/310166) ---
**Author:** ![gillytech](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/gillytech/32/3850_2.png) [@gillytech](https://community.hubspot.com/u/gillytech)\ **Post date:** [January 6, 2020, 9:56pm UTC](https://community.hubspot.com/t/hapi-key-security/13230/7 "2020-01-06T21:56:52Z")
@Hani-RT Yes, I believe this implementation would cover the feature request you linked to, but in a slightly different way. With a more robust API key auth system such as what I mention above, you would be able to keep one key alive while you roll out a new key in parallel. When you’re sure the old key is no longer being used (request logging per key would be good for making sure of that) then it could be deactivated. **HubSpot engineers:** Please take note of this, there will be a breach sooner or later with your current (risky) hapikey setup and you want to have all bases covered _before_ it happens. In the info security world, nothing happening ever is a _good_ thing! ---
**Author:** ![Hani-RT](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/hani-rt/32/32563_2.png) [@Hani-RT](https://community.hubspot.com/u/Hani-RT)\ **Post date:** [January 6, 2020, 10:21pm UTC](https://community.hubspot.com/t/hapi-key-security/13230/8 "2020-01-06T22:21:01Z")
Thanks for the reply, @gillytech! That’s fantastic. 🙂 ---
**Author:** ![gbe](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/gbe/32/35926_2.png) [@gbe](https://community.hubspot.com/u/gbe)\ **Post date:** [January 21, 2020, 9:48am UTC](https://community.hubspot.com/t/hapi-key-security/13230/9 "2020-01-21T09:48:11Z")
This is very important for us, as GDRP compliance rely on building a ‘registry of treatement’ + ‘inform in case of sensitive data breach’. In this registry, we have to indicate who is allowed to export which subset of information. Today, this means that each integration is allowed to export any sensitive data. Even worse, we have no way to identify if any of them did export sensitive data, while there are legal delay to publicly disclose security breaches. ---
**Author:** ![alvinlzg](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/alvinlzg/32/2679_2.png) [@alvinlzg](https://community.hubspot.com/u/alvinlzg)\ **Post date:** [February 11, 2020, 8:31am UTC](https://community.hubspot.com/t/hapi-key-security/13230/10 "2020-02-11T08:31:12Z")
This is a good idea. I am relatively new to HubSpot but we do use the API Keys for integration. OAuth seems to be a safer approach, but it also requires more effort. Some of the things we hope HubSpot would do is to allow the Admin account to have multiple keys instead of one account = one key and then share this key to other parties. It makes things worse when these keys allow the 3rd party to do everything. Next thing you know, your API Key is too old and you’re supposed to rotate them. So, who did I pass those keys to? Maybe I should rotate and see who comes back shouting at me? 🙂 ---
**Author:** ![rad](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/rad/32/4496_2.png) [@rad](https://community.hubspot.com/u/rad)\ **Post date:** [April 15, 2020, 7:44pm UTC](https://community.hubspot.com/t/hapi-key-security/13230/11 "2020-04-15T19:44:08Z")
Empty ---
**Author:** ![gillytech](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/gillytech/32/3850_2.png) [@gillytech](https://community.hubspot.com/u/gillytech)\ **Post date:** [April 16, 2020, 6:02pm UTC](https://community.hubspot.com/t/hapi-key-security/13230/12 "2020-04-16T18:02:31Z")
Guys I just saw the [API log in the changelog](https://developers.hubspot.com/changelog/api-call-logs-available-for-api-key-users) and I am SO excited ![16x16_smiley-very-happy.png.png](https://d2qpr2jzcazej7.cloudfront.net/original/2X/a/a83ec960612094a57cfb392e21c202c8e77b967c.png) Thanks for taking this into consideration and all your infosec minded customers will thank you! I would like to suggest an improvement to the new API Call Log: please include the IP address of which machine made the call. This way we can see if there is any unauthorized usage right away. ---
**Author:** ![sambitc](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/sambitc/32/35608_2.png) [@sambitc](https://community.hubspot.com/u/sambitc)\ **Post date:** [June 24, 2020, 6:46am UTC](https://community.hubspot.com/t/hapi-key-security/13230/13 "2020-06-24T06:46:41Z")
Having just one active key, makes the roation quiet hard in case if the keys are present inside the project. There will be a warranted downtime when u generate a new key and build and deploy the projects. So it is helpful if u add the support for temporarily accepting both old key and new key. ---
**Author:** ![mcraciun](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/mcraciun/32/48852_2.png) [@mcraciun](https://community.hubspot.com/u/mcraciun)\ **Post date:** [December 9, 2020, 3:17pm UTC](https://community.hubspot.com/t/hapi-key-security/13230/14 "2020-12-09T15:17:44Z")
+1 This would be so helpful!! ---
**Author:** ![mlevin2](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/mlevin2/32/64675_2.png) [@mlevin2](https://community.hubspot.com/u/mlevin2)\ **Post date:** [February 19, 2021, 6:05am UTC](https://community.hubspot.com/t/hapi-key-security/13230/15 "2021-02-19T06:05:45Z")
Has there been any update to this? My use case is as follows: - We are using CMS Hub for website content - We want to use it “headless” (yes, I realize CMS Hub was not designed to be used this way – long story) - We want to fetch page contents via API and render it in our own web app (not using CMS Hub to build the page, just getting the page as JSON) There doesn’t seem to be any concept of an API key with read-only access such that we could fetch the page client-side in our app without exposing a key with full access. Aside from fetching the content using the key server-side, does anyone have a suggestion for how to realize this use case? Thanks ---
**Author:** ![gillytech](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/gillytech/32/3850_2.png) [@gillytech](https://community.hubspot.com/u/gillytech)\ **Post date:** [February 19, 2021, 6:16am UTC](https://community.hubspot.com/t/hapi-key-security/13230/16 "2021-02-19T06:16:48Z")
@mlevin2 I don’t think there’s a way to do this. The HAPI key grants god-mode access to your HubSpot portal. You could check out the OAuth-based authentication that’s available. That gives you more granular access to the features of the API afaik. ---
**Author:** ![gillytech](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/gillytech/32/3850_2.png) [@gillytech](https://community.hubspot.com/u/gillytech)\ **Post date:** [February 19, 2021, 6:17am UTC](https://community.hubspot.com/t/hapi-key-security/13230/17 "2021-02-19T06:17:46Z")
@rad Is there any update on the roadmap for this idea? Also, quite interested in the calling IP address on the API Call Log. Any info would be appreciated. ---
**Author:** ![Guy\_Dawson](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/guy_dawson/32/35493_2.png) [@Guy\_Dawson](https://community.hubspot.com/u/Guy_Dawson)\ **Post date:** [May 6, 2021, 10:17am UTC](https://community.hubspot.com/t/hapi-key-security/13230/18 "2021-05-06T10:17:50Z")
Being able to keep an old key active while a new key is being ‘rotated in’ is key to preventing integration downtime when rotating the API key. We want to be able to: - create a new key - distribute the new key - use the new key - stop using the old key - monitor any old key usage in the logs and resolve - disable/delete the old key With multiple systems and releases we don’t expect to be able to switch every integration from the old key to the new key ‘in an instant’. ---
**Author:** ![DPolikoff](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/dpolikoff/32/29892_2.png) [@DPolikoff](https://community.hubspot.com/u/DPolikoff)\ **Post date:** [May 28, 2021, 4:05pm UTC](https://community.hubspot.com/t/hapi-key-security/13230/19 "2021-05-28T16:05:12Z")
I shouldn’t be forced to hand over the “keys to the kingdom” to an external vendor of ours working with us on an integration project. ---
**Author:** ![PSMS](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/psms/32/82389_2.png) [@PSMS](https://community.hubspot.com/u/PSMS)\ **Post date:** [June 2, 2021, 12:11pm UTC](https://community.hubspot.com/t/hapi-key-security/13230/20 "2021-06-02T12:11:01Z")
@rad, you have put this into “in planning” status April 2020, can you give an update? It there an **expected timeline** for delivering this feature? Can we read up on what you folks are planning to implement? Thanks [Next page](https://community.hubspot.com/t/hapi-key-security/13230.md?page=2)