Upcoming changes to the public API demo account

Dadams · ‎Jul 11, 2019

Update: These changes are now live, and the demo API key will only be allowed to make GET requests

When HubSpot launched our first public APIs in 2010, we created our public API demo account so that developers would have an account that could be used to test those new APIs. This was years before the launch of HubSpot's free CRM, so at the time the only alternative to the public demo account was to test against your paid HubSpot account that you were using for your actual business.

Since that initial launch, we've expanded the number of public APIs significantly, and we've released several new tools for developers, including things like our free test accounts, without any major updates to that original API demo account. With the overall growth of the HubSpot platform, as well as the support for our newer developer tools, that demo account is no longer the best way to test your integration.

We want to make sure that it's still easy to quickly see the data that is returned by HubSpot's APIs. However, once you're ready to start building your integration, you'll want to create a separate test account for any testing that you need to do.

What’s happening?

Beginning on Friday, August 9th, our public API demo account (accessed using the 'demo' API key) will only be allowed to make GET requests. Requests made using other methods (such as PUT, POST, or DELETE) will return an error.

Additionally, login will be disabled for the demo account, as the testapi@hubspot.com user for the demo account will be deactivated.

What’s changing?

As mentioned above, GET requests will continue to work as they do now, but any other request methods will return an error. If you have any tests running against the demo account using the 'demo' API key, tests that only make GET requests may continue to work, but any requests that manipulate data using other request methods will begin to fail.

The error response for non-GET requests will be a 403 error response code with the following format:

{
  "status": "error",
  "message": "Only GET requests can be made to HubSpot's demo account. You can create a test account to try other methods (https://developers.hubspot.com/docs/faq/how-do-i-create-a-test-account).",
  "correlationId": "f44e1352-e329-41e7-8efc-23ed7a83e5ef",
  "requestId": "eb89d11e86d87c6169b334eb318e143e"
}

Additionally, since the testapi@hubspot.com user will be deactivated, that user will no longer be able to log in to the account. This means that OAuth connections will no longer be allowed with the public demo account.

If you have any tests running against the public demo account, you will want to create a test account, and move any tests over to that new test account.

Test accounts have access to API keys, so you will be able to create a test account, generate a new API key for that account, and then swap that API key for the demo key. However, we do recommend that any testing be done using OAuth tokens. API requests made to a test account authenticated with an OAuth access token will automatically renew the test account.

When is this happening?

This change will happen on August 9th 2019.

If you have any questions please let us know by replying to this thread.

fonji · ‎Nov 5, 2019

Hi,

TL/DR: this makes it difficult to have an open source library that uses hubspot's API, with a test suite that can be used in the long term without changing the configuration and with many contributors.

It's great to make little tests for a small dev team though.

I want to make changes to the ruby gem, mainly adding features.

Of course, it needs testing, and for that reason I currently need to make POST requests.

Until now the code used the demo API key, with a tool named VCR to record HTTP requests in "cassettes" (and so bother the real servers only once).

It seems like we are supposed to use test accounts now.

But there are problems with this solution:

First, the expiration of the test accounts make it difficult to have tests that work in the long term.

If for some reason we need to regenerate VCRs cassettes, e.g. to have them updated after an API change, the key and portal id must change.

If we want to make a new test using the test portal after expiration, and we create a new one, we need to update all the test suite to the new portal, as the key is shared between tests cases.

Also, this leads nicely to the second problem: the ruby gem is open source.

AFAIK, test portals aren't accessible to everyone in the world.

So if I, simple contributor, need a new test portal, am I supposed to ask for one to the gem's owners?

I guess you can see that this isn't an ideal solution. Mainteners have to do mundane tasks without a real value, they should concentrate to validate contributions.

Is there a solution I don't see? How do you maintain your public libraries?

APIs & Integrations