Upcoming: API Key Sunset

Developer Support Developer Announcements
1

What’s changing?

API Keys have been one of three authentication methods supported by HubSpot APIs. However, as part of ongoing efforts to protect our customer’s data, we will be sunsetting API Keys.

As a result of this change, integrations will instead be required to work with Private Apps. Private Apps offer tighter security and allow more granular control over your integrations and account data than legacy API keys.

What this means for developers:

With the introduction of Private Apps, users who previously developed on HubSpot and utilized API Keys will now be required to migrate existing integrations from using API Key authentication to using Private Apps instead. Instructions for how to migrate existing integrations can be found here.

Why the Change?

Private Apps allow you to set up a separate static access token for each integration. Private App access tokens are also scoped like OAuth access tokens, so you can control the access that each integration has to your HubSpot account.

Private Apps work much the same as API key integrations do, with the main change being that they use a static access token in the Authorization HTTP header, instead of using the API key in a query parameter to authorize the API request. No other changes should be required of your integration aside from updating the authentication method.

If your integration is intended to be used by multiple HubSpot accounts, you must update your integration to be a Public App using OAuth 2.0. Private Apps cannot be used for multi-account apps. OAuth 2.0 provides the same security features as Private Apps, but provides a much better experience for HubSpot users, allowing them to quickly connect their HubSpot account to your app without additional code.

When is this change happening?

After November 30, we will begin the process of deprecating API Keys and your API keys will no longer be supported by HubSpot. You will therefore be using API keys at your own risk.

As of July 15, 2022, we no longer allowed new API keys to be created. Existing API keys will work until November 30th, but accounts which did not have an API key, as of July 15, 2022, will not have access to create a new API key.

In order to begin using Private Apps immediately, please see the documentation for Private Apps.

Developer Account API Keys, for configuring public apps, will still be available for use in Developer Accounts after November 30, 2022 and will not be affected by the API Key Sunset.

The migration guide linked above will remain your source of truth for information and questions regarding the API key sunset. If you have a question which hasn’t been answered, reach out to Customer Support.

Updated October 18

2

There is no way to retrieve “quotes” with private app key.

3

@MLi9

If you are referencing the Quotes object, this is available with private app authentication

4

Ok, that’s good to hear. I haven’t try it recently, but it does not work back in April

5

I double checked before posting that and I was able to retrieve quotes so you should be good to go :+1:

6

Woah! Huge change!
How would authentication work in workflow custom code actions? Would we need to create a private app for that as well?

7

I just created a private app and it is very easy to use for custom code actions! Problem solved.

8

I have just deployed a windows service ( not an app ) for a client that uses an API Key aka HapiKey to syncronise data between their ERP and HubSpot. Will this just stop working at the end of November?

9

@GKenyon ,

Yes. you will need to migrate to a private app. Here is a link to the migration guide

10

Thanks Dennis,

For the benefit of anyone else using C# and an API key to access the API from an external application this is all you will need to change.

I created a private app - assigned scope and the creation generated a token.

This is an excerpt from the original code (using RestSharp)

hapiKey = “your_api_key”; // real app reads this from a config

var client = new RestClient(baseURL);

var request = new RestRequest(“crm/v3/objects/companies/”, Method.Get);

request.AddQueryParameter(“hapikey”, hapiKey);
// etc..

This is what you need to change.

token = “your_token”; // real app reads this from a config

var client = new RestClient(baseURL);

var request = new RestRequest(“crm/v3/objects/companies”, Method.Get);

request.AddHeader(“Authorization”, "Bearer " + token);
// etc.

11

Thank you so much!

12

Happy it helped you :blush:

13

We are using the HubSpot APIs and API keys within HubSpot’s serverless functions. How can we adapt to this change for this scenario?
How can we implement a token-refresh, if there’s no persistence in the serverless environment?

14

Hey @mzweng, you would still be able to use a static key, you would just need to generate a “private app” key with the correct scopes. Not a huge change, but still cumbersome if you support a large number of functions and portals.

15

Hi @Mark_Ryba, ah, ok I see. That is good. Thank you very much!

16

@mzweng

You can create a Private App with the needed scopes, store it as a secret (just like with API keys) and make API calls with it. No need for token refresh :grinning_face:

edit -- just saw that Mark beat me to the punch!

17

Really wish there was an answer here :upside_down_face:.

I’m imagining that env variables would still be accessible via the secrets. So we are just generating a secret’s value from a different location. I could be wrong

18

Respectfully, This is not enough time to be able to pivot for all of the clients for solutions providers. This is not a small change by any means but giving 6 months seems unfeasible and a big hit to service providers who (like us) have literally hundreds of custom apps and integrations amongst customers built leveraging the API over the years.
For the record, I agree with the direction but a Great example of a major change and giving the ramp to implement changes would be how google is announcing the change for GA4.

PS: a heads up to partners should have happened before this was public knowledge.

19

100% ! Couldn’t agree more with what you are mentioning.
I would add that it is unclear how we would be doing things that require API key but is not an app:
- One time job/request/script (such as create a custom object, or a datetime property, or a batch update or extract, test an API endpoint, etc.)
- Custom code actions (workflows, chatbots)
- Serverless functions
Would we need to create a private app for every small task? That doesn’t make sense…

20

To add to your list:

- webhook subscription management