Skip to content
Back to Blog
Marketplace

HubSpot Sandbox or Developer Test Account, Where to Test Your App

Jun 18, 2026
SCSunny Chauhan
HubSpot Sandbox or Developer Test Account, Where to Test Your App

If you are building an app that your customers install in HubSpot, the place to test it is a developer test account, not a sandbox. Test accounts are free, you can run up to 10 of them, and you can set each one to the Hub tiers your customers actually pay for. HubSpot sandboxes belong to a customer's Enterprise production account and copy that account's setup. You meet them when an Enterprise customer wants to try your app before it touches their live CRM.

That split matters for a SaaS company because the app you test is the app every customer installs, and you keep maintaining it across their accounts after launch. Appnigma's marketplace apps service covers this case. It delivers "a native app, marketplace listing preparation, and review support" for HubSpot and Salesforce. If you are a HubSpot admin testing workflows in your own company's account, HubSpot's guide to creating a sandbox and deploying changes to production is the page you want.

Updated October 2026. Checked against HubSpot's account types, configurable test account, app management, OAuth scope and Marketplace listing documentation. This update separates developer test accounts from sandboxes and corrects which installs count toward listing and certification. It also replaces the separate Developer Account steps with the current flow and removes an example that had no source.

Four environments, and the one built for app testing

HubSpot's account types page lists four environments a builder can run into. Only one of them is built for testing an app across many customer setups.

EnvironmentWho can create itHow manyWhat it starts withBest use for an app builder
Developer test accountAny standard HubSpot accountUp to 10Empty, with Enterprise trials by default or the tiers you pickBuilding and testing your app
Standard sandboxEnterprise accounts, Super Admins1 (more as an add-on)Copy of the production setup, optionally 5,000 contactsA customer trying your app before production
Development sandboxEnterprise accounts, through the CLI1CRM object definitions onlyEarly proof of concept inside one company's account
CMS sandboxAnyone, freeNot statedFree tools plus Content Hub EnterpriseWebsite themes and templates

The test account row is the one most guides skip. HubSpot describes test accounts as "free HubSpot accounts with access to a 90-day trial of many enterprise features," and they "cannot sync data with other accounts." Sandboxes are the opposite. The knowledge base article on sandboxes lists only *Enterprise* tiers, and the CLI account commands reference says "a production account can have one standard sandbox and one development sandbox at a time."

There is no separate developer account to sign up for anymore. HubSpot's developer overview says "as of March 9, 2026, all legacy developer accounts were migrated to standard HubSpot accounts." Your apps, test accounts and listings now live under Development in a normal HubSpot account.

How to create a test account and install your app

You create a test account from Development, then Testing > Test Accounts, and click Create developer test account. By default the account gets Enterprise trials for every Hub. A Customize my test account checkbox lets you pick a tier per Hub instead, which HubSpot's configurable test accounts guide says helps you "simulate different HubSpot subscription and tier combinations."

The same guide documents a CLI route for projects on platform version 2025.2 or later with CLI 8.3.0 or later. That route is the one to use if you want test accounts rebuilt the same way every time, for example in CI. The commands below come from that guide and are not tested here.

Generate a config file, then create an account from it:

hs test-account create-config
hs test-account create --config-path ./starter-sales.json

Load CSV records through the CRM imports API:

hs test-account import-data
{
  "accountName": "starter-sales-customer",
  "description": "Sales Hub Starter, everything else free",
  "marketingLevel": "FREE",
  "opsLevel": "FREE",
  "serviceLevel": "FREE",
  "salesLevel": "STARTER",
  "contentLevel": "FREE"
}

Two details trip people up. The guide shows the flag as --config-path, while the CLI command reference lists it as --config, so check hs test-account create --help on your CLI version. And import-data won't create custom properties for you. HubSpot says "you'll need to create them in the account before importing."

Installing your app is a normal OAuth install. You open the install URL, https://app.hubspot.com/oauth/authorize?client_id=...&scope=...&redirect_uri=..., choose the test account and approve. HubSpot's OAuth guide says the installing user must "be a Super Admin or have HubSpot Marketplace Access permissions." The same page logs each authorization request, grant and token exchange in your development settings, which is the first place to look when an install fails.

Why an install that works for you fails on a Starter account

Developer test accounts default to Enterprise trials, which is why a test can pass for you and fail for a customer. Many scopes depend on the customer's subscription. HubSpot's scopes reference marks automation, which covers custom workflow actions, as "available to *Professional* or *Enterprise* accounts only." It notes that custom object data is "only available to *Enterprise* HubSpot accounts." A test account on Enterprise trials has all of that, so your install always succeeds.

A real customer on Sales Hub Starter is different. If your install URL lists a conditionally required scope they don't have, HubSpot's scopes page says "the installation will fail." Optional scopes behave better because the customer can decline them and still install. But your app then has to work without that data, and only a lower-tier test account shows you whether it does.

A practical way to spend the 10 accounts is one per tier your app supports, plus two fixed ones. As a worked example, an app that reads Sales Hub data and offers a custom workflow action could use five accounts. That means Sales Hub Free, Starter, Professional and Enterprise, plus an all-Enterprise account that never changes and serves as your demo and review account. Add a sixth for CI and you still have four spare. If the app spans two Hubs, testing every combination would take 16 accounts, so test each Hub at the lowest tier your scopes allow instead.

Which installs count toward HubSpot listing and certification?

None of your test installs count toward listing, and some don't count toward the pre-listing cap either. The Marketplace listing requirements ask for "at least three active, unique installs." Active installs are "unique HubSpot production accounts, unaffiliated with your organization, showing successful app activity within the past 30 days." A test account is neither a production account nor unaffiliated.

The cap before listing is generous for testing. HubSpot's app management page says a Marketplace OAuth app "can be installed in up to 25 accounts (not including developer test accounts)" until it is listed. So your 10 test accounts are free, and the 25 slots are for beta customers. Before you can use those slots you have to sign HubSpot's Acceptable Use Policy under Begin publishing. Until then, HubSpot says, "you won't be able to install your app in accounts other than developer test accounts." HubSpot doesn't say whether a beta customer's sandbox counts toward the 25. It is a separate account with its own install, so plan as if it uses a slot.

Certification is stricter again. The certification requirements say "test accounts will also be excluded." The page on applying for certification asks for an app "listed for at least 6 months" with "at least 60 active installs." It also asks for a YouTube demo video that is "at least three minutes long" and shows install, setup, the main features, disconnecting and uninstalling. Your fixed demo test account is the right place to record it, because nothing in it has been broken by last week's tests.

What changes when a customer installs your app in their sandbox

Larger customers often want your app in their standard sandbox before production. HubSpot's knowledge base says "integrations in your production account won't be connected automatically to the standard sandbox account" and recommends "connecting to the sandbox version of that integration." In practice, the customer installs your app a second time, into the sandbox, and your backend gets a second set of tokens for a different HubSpot account ID.

Your backend has to treat that as its own connection. HubSpot says contact, company, deal, ticket and custom object records "will have different IDs between sandbox and production accounts." Any mapping you store against the sandbox will be wrong once the customer moves to production. Key every stored record by HubSpot account ID as well as record ID, and expect the customer to reconnect and re-map rather than promote their sandbox setup. The sandbox also starts with at most 5,000 contacts copied from production, so a sync that looks fast there can take much longer on the real account.

This is the same discipline Salesforce ISVs know from scratch orgs. Salesforce's scratch org guide says they expire "in 1-30 days," with a default of 7. Teams that already rebuild scratch orgs from a definition file can treat HubSpot config files the same way. Appnigma's integration infrastructure page describes the pattern for customer integrations as "Validate the customer's workflows in a sandbox, then release through the deployment pipeline."

Mistakes that break app testing

  • Letting a test account expire. HubSpot's account types page says test accounts "will expire after 90 days if no API calls are made to the account." You can renew by API only "no more than 30 days before" expiry, with an OAuth token from an app in the same account. A nightly CI call keeps your demo account alive.
  • Testing only on Enterprise trials. The default hides every tier-gated scope, so the first Starter customer finds the failure for you.
  • Counting test installs toward listing. They never count. Recruit three unaffiliated customers early, because they also need activity in the last 30 days.
  • Expecting test emails to reach real inboxes. Marketing email from a test account only goes "to addresses of users who you've added to your developer test account."
  • Running bulk workflow tests without a ceiling. Test accounts cap workflow enrollment at 100,000 records a day, and further enrollments are dropped.
  • Seeding custom properties last. Create them before import-data, or the import can't map those columns.

Frequently Asked Questions

Does HubSpot have a sandbox for app developers?

Not in the usual sense. App builders use developer test accounts, which are free, up to 10 per account and configurable by tier. HubSpot sandboxes are an Enterprise feature for testing changes to one company's own account.

How many HubSpot test accounts can I create, and do they expire?

Up to 10 per standard HubSpot account. Each expires after 90 days without API calls, and you can renew it in the account or by API in the 30 days before it expires.

Do I need HubSpot Enterprise to test my app?

No. Developer test accounts are free in any standard HubSpot account. Only standard and development sandboxes need an Enterprise subscription.

Can I install an unlisted HubSpot app in a customer's account?

Yes, in up to 25 accounts before listing, not counting developer test accounts. You have to sign the Acceptable Use Policy under Begin publishing first.

Can Appnigma build and test our HubSpot app?

Yes. Appnigma's marketplace apps service builds the native app and provides "HubSpot listing review and certification support where eligible."

About the author

Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.

Sources

  1. HubSpot Developers, HubSpot account types
  2. HubSpot Developers, Developer overview
  3. HubSpot Developers, Configurable test accounts
  4. HubSpot Developers, Account CLI commands
  5. HubSpot Developers, Working with OAuth
  6. HubSpot Developers, Scopes
  7. HubSpot Developers, Manage apps in HubSpot
  8. HubSpot Developers, App Marketplace listing requirements
  9. HubSpot Developers, App certification requirements
  10. HubSpot Developers, Applying for app certification
  11. HubSpot Knowledge Base, Create a sandbox and deploy changes to production
  12. Salesforce Developers, Create scratch orgs

All Blogs

Bring the customer requirements and your current setup. Get a clear scope and delivery timeline to take back to them.