Sandbox Self-Test

Purpose

Every skill in this repo mutates or reads a live HubSpot portal, and no two portals are alike. This skill lets anyone — a contributor before opening a PR, an admin before trusting the toolkit with production, or the maintainer after a HubSpot API change — verify the whole toolkit against a disposable portal they bring themselves. HubSpot gives every account up to 10 free developer test accounts, so there is no shared test infrastructure to maintain and no credentials in the repo: bring your own sandbox, run the suite, read the report, throw the sandbox away.

Key Constraint

This suite seeds, mutates, and deletes data. It must never touch production. The lockout is enforced in code, not by convention:

1. The suite reads its own env var, HUBSPOT_SANDBOX_ACCESS_TOKEN — it never reads HUBSPOT_ACCESS_TOKEN, so a production token in your .env cannot be picked up by accident.
2. Every script (not just preflight) calls GET /account-info/v3/details before acting and refuses unless accountType is DEVELOPER_TEST or SANDBOX. The check fails closed — any error verifying the account type is a refusal — and there is no override flag.

Prerequisites

• A developer test account (free: HubSpot Settings > Testing > Developer test accounts, up to 10 per account, 90-day expiry renewed by API activity) or a standard sandbox (Enterprise plans)
• A private app inside that test account with scopes: crm.objects.contacts.read/write, crm.objects.companies.read/write, crm.objects.owners.read, crm.lists.read/write, automation
• Its token in .env as HUBSPOT_SANDBOX_ACCESS_TOKEN (keep it separate from your production HUBSPOT_ACCESS_TOKEN)
• Python 3.10+ with uv