Updated June 18, 2026 by Sunny Chauhan.

If you've shipped Salesforce Managed Packages, you know the rule: never develop against a real customer org. HubSpot has the same rule and the same answer for it: a sandbox account. The HubSpot sandbox is a free, full-feature HubSpot portal that lives under your Developer Account and lets you build, install, and test your Marketplace app without touching real customer data. It's also where you'll generate the three test installs HubSpot requires before they certify your listing. Here's the actual setup walkthrough, what sandboxes can and can't do, and how they fit the certification flow.

Pro Tip

TL;DR A HubSpot sandbox is a developer-owned HubSpot portal for testing apps. It lives under your Developer Account, has most production features, and lets you install your own app for end-to-end testing. You need at least one for development and you'll lean on three for the certification install requirement. Set up: 1/ Create a Developer Account, 2/ Create a sandbox from inside it, 3/ Install your app in the sandbox via OAuth, 4/ Test. Sandboxes are free and you can create multiple. Production data does not flow between sandboxes and customer portals.

A HubSpot sandbox account is a complete HubSpot portal: CRM objects, workflows, forms, dashboards, the lot. The differences from a production portal are mostly about who owns it (you, the developer) and what data lives in it (only what you put there).

Three things sandboxes do that production portals don't:

→ They live under your Developer Account. You can create them with one click from the Developer Account UI. You manage them, not the customer.

→ They install your unpublished app. You can install your app into a sandbox before the app is listed in the Marketplace. This is how you do end-to-end testing.

→ They count toward the 3-install certification requirement. HubSpot requires that your app has been installed at least three times in different HubSpot accounts before they certify your listing. Sandboxes count.

Three things they don't do:

1/ They don't have production data. Anything you need for testing, you create yourself.

2/ They can't share data with each other or with a customer portal. Each sandbox is an island.

3/ They expire under certain conditions. Sandboxes tied to a Developer Account stay alive as long as the account is active. But test portals created for short-term experiments may auto-archive after inactivity.

Three steps. Should take 15 minutes end to end, assuming you don't have a Developer Account yet.

Go to developers.hubspot.com and sign up. The Developer Account is separate from any customer HubSpot account you might have. It's the workspace where you create apps, manage Marketplace listings, and spin up sandboxes.

Required: email, password, name. No payment information at any point. The Developer Account is free.

Inside your Developer Account, open the Test Accounts section. Click Create app test account. HubSpot provisions a new portal with a unique portal id under your developer ownership.

What you'll get: → A new portal id (a 7-8 digit number) → A login URL specific to that sandbox → Full Hub access (Marketing Hub, Sales Hub, Service Hub, CRM, Operations Hub)

You can create multiple sandboxes per Developer Account. I'd recommend at least three: 1/ One for active development (you keep breaking things here) 2/ One for QA and demo recording 3/ One for the certification install (you treat this one like a customer portal)

This is where the loop closes. Your app, however incomplete, can be installed into a sandbox via the OAuth flow.

The flow:

1/ In your Developer Account, get your app's client_id 2/ Construct the OAuth install URL: https://app.hubspot.com/oauth/authorize?client_id=<client_id>&redirect_uri=<your_url>&scope=<scopes> 3/ Open that URL in your browser 4/ Log into the sandbox (use the sandbox-specific login, not your developer account) 5/ Approve the install 6/ HubSpot redirects to your redirect_uri with an authorization code 7/ Your server exchanges the code for access and refresh tokens

Once installed, the app is wired up. Webhook subscriptions fire on relevant sandbox events. API calls work against the sandbox's data. The same flow a real customer would experience, just against a portal you own.

Three patterns I've seen trip people up:

→ Email sending volume is capped. Sandboxes have a low cap on transactional and marketing emails. If your app sends a lot of email as part of the test flow, you'll hit the cap and assume your code is broken when it's actually the sandbox limit.

→ Some integrations require paid Hubs. Sandboxes ship with most Hubs enabled at trial-level. But specific features (advanced workflows, custom objects in some tiers, Operations Hub Enterprise functions) might be limited. If your app depends on a feature that needs a paid Hub, test in a sandbox that explicitly has that Hub enabled.

→ Sandbox data doesn't auto-populate. You'll have to create test contacts, deals, and tickets by hand or seed them via API. A blank sandbox is not a usable test environment.

For seeding data programmatically, I'd recommend writing a small script that calls the CRM API to create 50-100 test contacts and deals during your initial sandbox setup. This pays for itself many times over once you're iterating on actual app behavior.

HubSpot requires three installs before certification (HubSpot Marketplace certification requirements). Sandboxes count as installs. So you can satisfy the 3-install requirement entirely through sandboxes if you don't have beta customers yet.

That said: certification reviewers care more than the raw install count. They want to see:

1/ Active usage of the scopes your app requests (the scopes have been used in API calls within the last 30 days) 2/ A working demo or guided walkthrough (the March 2026 change replaced test credentials with demo videos) 3/ Functional core flows (the app actually does what your listing says it does)

The right pattern: use one sandbox as your "demo portal" where every flow your listing promises has been exercised. Record a video walking through it. That video is part of your submission. Reviewers watch it and check that what they see matches what your listing claims.

Appnigma generates Salesforce 2GP Managed Packages and pairs each package with a scratch org for testing. The pattern is the same: never test against a customer org, always test in a developer-owned environment first. For HubSpot, the equivalent is the sandbox. The reasons (data safety, blast-radius limits, fast iteration) are identical across both ecosystems.

• [ ] HubSpot Developer Account created → Yes / No

• [ ] At least three sandboxes spun up under the Developer Account → Yes / No

• [ ] Your app installed via OAuth in each sandbox → Yes / No

• [ ] All requested scopes have been used in API calls (within last 30 days) → Yes / No

• [ ] Sandbox data seeded (50+ contacts, 20+ deals, sample tickets) → Yes / No

• [ ] End-to-end demo flow recorded as walkthrough video → Yes / No

• [ ] Email sending cap considered (if your app sends emails) → Yes / No

• [ ] No real customer data has touched the sandbox → Yes / No

A B2B CPQ product (think Salesbricks-style) wanted to extend from Salesforce to HubSpot. They created their HubSpot Developer Account on a Monday, spun up three sandboxes, and installed their first iteration on Tuesday.

The Tuesday install worked but their webhook handler errored on deal.propertyChange because the sandbox had no deals. They wrote a 50-line seed script to populate 100 deals and ran iterations against real data shapes. By Friday they had a working app, a clean demo video, and a passing certification submission.

The piece they got right: treating one sandbox as the "demo and submission" environment. They never broke that one. The other two were for experimentation. When certification reviewers asked for the demo video, the demo sandbox already had clean data and the recorded walkthrough was reproducible.

A HubSpot sandbox is a developer-owned HubSpot portal for testing apps. It lives under your Developer Account, has most production features, and lets you install your Marketplace app before listing. Sandboxes are free and you can create multiple (HubSpot Developer Account documentation).

HubSpot allows multiple sandboxes per Developer Account. The practical limit is around 10 active sandboxes per developer account in 2026, which is more than most builders need. I'd recommend at least three: development, QA, and certification.

No. Sandboxes start empty. Any data you want to test against has to be created manually or seeded via the CRM API. This is a feature, not a limitation: it prevents customer data from leaking into developer environments.

Yes. You can install your app into a sandbox via the OAuth flow as soon as the app exists in your Developer Account, well before it's listed in the Marketplace. This is the primary way to test Marketplace apps end-to-end.

Yes. The three-install requirement is satisfied by any combination of sandbox installs and real-customer installs. Some teams use three sandboxes; others mix one or two beta customers with one sandbox. Both work.

Three main ones: low email sending cap, some advanced features may be restricted by Hub tier, and you have to populate data yourself. None of these are blockers; just know them before testing.

Construct the OAuth authorization URL with your app's client_id, your redirect URI, and the scopes you want. Open it, log into the sandbox, approve the install. HubSpot redirects to your URI with an authorization code; exchange the code for tokens. See our HubSpot OAuth scopes guide for the full token exchange flow.

Sunny Chauhan is the founder and CEO of Appnigma AI, a no-code platform that generates Salesforce AppExchange-ready Managed Packages from natural-language prompts. He holds Salesforce certifications in Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate. The sandbox-first development pattern Appnigma applies to Salesforce scratch orgs maps directly to HubSpot sandboxes: test in a developer-owned environment, never against customer data, seed enough data to exercise the real flows.

Originally published June 18, 2026. Last reviewed June 18, 2026. Sandbox capabilities verified against HubSpot's Developer Account documentation and Marketplace certification requirements current as of the published date.

• HubSpot Webhooks Implementation Guide

• HubSpot OAuth and Scopes Complete Reference

• HubSpot API Key Management Guide

• HubSpot API Rate Limits Guide

• HubSpot Custom Integration: Complete Build Guide

• HubSpot App Cards and UI Extensions

1/ HubSpot Developers, Developer Tools Overview 2/ HubSpot Developers, Creating a Test Account 3/ HubSpot Marketplace Certification Requirements 4/ HubSpot Developers, OAuth Quickstart Guide

How many sandboxes does your current workflow use, and are any of them treated as the "untouchable demo" portal?