Upcoming: API Key Sunset

[Dadams]

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

[danmoyle]

@dennisedson to the rescue! 

For real though, this is good to read. I do hope it goes smoothly for thos who need it. 

[gillytech]

What about Ecommerce Bridge support in Private Apps?

[rbutler-jpi]

What about the Public Email API Alpha that my company is using?

Last time I checked in with the Development team handling this on your side, the Public Email API Alpha has basically not had any updates to it in some time in preperation for a newer version that's got no release date or information available and it does not support using the "private apps" side of HubSpot. We use this Public Email API alpha A LOT. Can you please clarify ASAP if this has been considered otherwise there are going to be huge implications for us....

[louischausse]

@dennisedson @Dadams  As far as I know, the e-commerce bridge API is not compatible with private apps yet. Only API key or OAuth according to documentation.

Would following the doc for ecom bridge OAuth work with private app tokens?

In short, would a private app access token in the header work (i.e. Authorization: Bearer {token})?

[gillytech]

I don't have the time to try it out right now but if you or anyone else has any luck with this I woud really appreciate an update! Meanwhile I am going to try to get a note in with the product team to see where Private Apps support for Ecomm Bridge is at on the roadmap.

[louischausse]

Keep us posted here please! @gillytech 

[TimOstheimer]

This isn't nearly enough time.

[nickdeckerdevs1]

Hi! I applaud moving towards this, however it looks like the timeline was made up by some corporate person that is out of touch with their partners and developers. Were people consulted? The slack champions group? HubSpot Partners that are dev and integration focused? Developer advocates? This is the timeline yall figured out was best?

Whatever the case really is -- is too short of a timeline. HubSpot developers have received this email as their one email to know that they need to update this. I have clients I've built work for that I'm no longer in their portal. I have plenty that I'm in their portal. No client is going to know they need this migrated, this is all on the developer/partner/agency/freelancer to reach out to the client and let them know that they need to pay more money to still keep their integration working.

1) Can we lengthen the deadline?

2) Is HubSpot willing to put money behind this to ease the cost to their clients?

3) Is it possible to grandfather current integrations in? I realize this might be much harder, so maybe option 1 and 2 are easier to implement.   

I mean, option 1 seems like the easiest thing to do here. I have to search through years of emails and reach out to clients I haven't spoken to in years. It just seems like a very large task right now with a very small timeline.

I have a whole lot of other feedback but I'm going to keep that to myself as none of it is constructive. We have a special slack group that could be reached out to, as well as developer advocates in the community that are hubspot employees that I believe would have asked for more time than 6 months. I hope this is addressed and the timeline for implementation is lengthened. 

Also, is there some plan to support this? When a HS customer reaches out via chat and they don't know why their integration isn't working, are there some preferred developers you are suggesting look into it? On December 1st, what's the plan to deal with this fallout?

Sorry if this response is all over the place, I've tried to take a few hours to respond, but I keep coming back to the only thing that makes sense - that no one cares about the repercussions on this -- sorry, too bad developers, just figure it out. I don't want to think that is the way HubSpot is positioning this.

[TimMunro]

Please clarify how to create custom objects without the API key. Object schema  endpoints detailed here https://developers.hubspot.com/docs/api/crm/crm-custom-objects (e.g. POST/crm/v3/schemas) stipulate that only the API key may be used. Thanks, Tim

[Jaycee_Lewis]

Hey, @TimMunro, please have a look at this guide — How to Build a Custom Object Using Private Apps

Best,

Jaycee

[gillytech]

I am concerned that my Ecommerce Bridge implementation will stop working. Private Apps does not (AFAIK) support Ecommerce Bridge functions and it's the only thing I use API Keys for. Everything else is on Private Apps. What is the plan to provide Ecomm Bridge functionality in Private apps?

[louischausse]

I have the same concern. @dennisedson can you get us an answer on this one please?

[arlogilbert]

The July date seems reasonable, but the November date is nowhere near enough notice.

HubSpot wants companies to build on top of your APIs which means that entire companies (mine included) have built on top of CMS/CRM/File APIs for myriad use cases across hundreds of services.

Given that replacing the API key is not as simple as just swapping out keys for the private app equivalent, but actually does require code level changes, this is nowhere near enough time to fully deprecate the keys. A year notice at a minimum would be acceptable.

[Skipio]

I use my developer api key in combination with an OAuth public app in order to create/manage webhooks, as the public app doesn't have a way to do this. How am I supposed to use the Webhooks API without an API Key?

The webhook api docs state that the only way to use the endpoints is with a "developer API key":

---

"You can use the following [webhook] endpoints and your developer API key to programmatically configure webhook settings for an app."

Emphasis added - source: https://developers.hubspot.com/docs/api/webhooks#manage-settings-via-api

Are you planning on adding a different way to authenticate against the webhook endpoints? 🤔

[Skipio]

Wait, at the end of your post you have "Developer Account API Keys, for configuring public apps, will still be available for use in Developer Accounts"; does that apply to me for the webhook endpoints?

I'm confused on the difference between "API Keys", "Developer Account API Keys", and "Developer API Keys"... aren't they all the same?

[dennisedson]

@Skipio 

Webhook APIs and other APIs that use Developer Account API Keys will continue to work after Nov. 30. Developer Account API Keys are different from the API Keys in Customer Portals. Developer Account API Keys  give developers access to Public App Configuration in the Developer Account.    

[Skipio]

Thank you for clarifying this @dennisedson ! 

[ABerggren]

This is very critical. As 6 months is not longe time. Espacially when 2 of those is summer. Im actiually interested if private apps actually always make the job done as an API can do? As all the one time/call jobs. 

[remingtonbegg]

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.

[danmoyle]

Echoing @remingtonbegg here. A major change like this takes time and attention. 

[Kevin-C]

I must agree, with @remingtonbegg  @Mark_Ryba and other's points here. This is going to be a massive hit to partners and clients. One of us is going to have to bear the cost of this change. If this was a beta change like GraphQL limits would be a non-issue and expected. But a full feature sunset like this paired with the looming Hubl function limitation is very…salesforce.