Hubspot Developers Updates & Release Notes

June’s developer updates include new CRM and customer success signals, cleaner subscription-status histories, expanded Knowledge Vault support for structured data, app object activity association controls, quote module customization, and several CLI improvements. This roundup also covers custom event timeline configuration and new Remote MCP server capabilities for content analytics and landing page creation.

Join the discussion in the Developer Community.

• Current Customer system property now available
• Deduplication of repeated subscription status updates from automations
• Knowledge Vaults now support structured data files
• Automatic activity associations are now available for app objects
• Custom-coded modules are now available for HubSpot quotes
• HubSpot CLI authentication is now centralized
• App logs are now available in the HubSpot CLI
• Custom event timeline cards can now be customized
• Content analytics and landing page creation now available in the Remote MCP server

Current Customer system property now available

HubSpot now provides a system-managed Current Customer property (hs_current_customer) on companies, contacts, and custom objects that flags whether a record is a current customer. It powers default filters in the Customer Success workspace, and you can read it and filter or search on it through the CRM API like any other property — though it's system-managed and read-only to integrations (HubSpot computes and sets the value). New accounts default to lifecycle stage = customer; you can keep that or redefine "current" using a single property, a set of lifecycle stages, or the advanced filter builder. Existing accounts can adopt it without changing their current views. Values are yes, no, or empty (unevaluable/cleared).

Deduplication of repeated subscription status updates from automations

HubSpot is now updating how repeated subscription status updates from automated sources, including workflows, integrations, and API calls, are recorded. Instead of recording subscription statuses for a contact repeatedly When an automated source sends the same subscription status multiple times within a 24-hour period with no meaningful change, HubSpot may consolidate those entries instead of recording each one separately. This makes subscription history cleaner and easier to audit.

Meaningful changes will still be recorded. These include:

• The opt state changes (e.g. subscribed -> unsubscribed)
• The legal basis to communicate is different
• The source type differs (e.g. a contact taking action directly vs. an automated workflow)

Only automated sources will be affected by this deduplication effort.

Knowledge Vaults now support structured data files

Knowledge Vaults now support uploading and querying structured data files — xlsx, csv, json, and xml — so agents can answer analytical and aggregation questions directly from your tabular data.

• Upload the supported file types via the Knowledge Vault file picker; the analysis tool is enabled by default.
• For natural-language lookups, keep using the standard Knowledge Vault tool.

Automatic activity associations are now available for app objects

You can now configure automatic activity associations with app objects. This ensures that activities logged to an app object are available in the records’ timeline, removing the manual step of navigating between associated records and relevant timeline activities, such as logged emails and calls.

Account admins must opt-in to this feature by configuring it in account settings. This means admins can choose which activity types are automatically associated with app objects.

Please note: You can only configure this logging behavior for app objects where an association exists according to the data model configured by the connect app. If the app object is not associated with an activity or a record, the setting will be disabled.

Custom-coded modules are now available for HubSpot quotes

Developers, admins, and solutions partners can now build custom CMS React modules that can be embedded directly into quote templates or individual quotes. These modules make it possible to customize or replace quote sections, such as line item tables, terms and conditions, payment schedules, or fully custom quote layouts, while pulling data from HubSpot CRM or external systems. Teams can use this to create more interactive, data-rich, and brand-controlled quoting experiences for CPQ workflows. Learn more in the high-level overview or explore the custom CMS React modules documentation and sample GitHub project.

HubSpot CLI authentication is now centralized

HubSpot CLI now uses a global authentication model, so developers can authenticate accounts once and link them to specific project directories as needed. Credentials are stored globally in ~/.hscli/config.yml, while each project’s linked accounts are tracked in .hs/settings.json, making account context clearer and reducing the risk of deploying to the wrong account. Developers can use hs account link, hs account default, hs account unlink, and hs account current to manage project-specific account associations. Legacy .hsaccount files are migrated automatically where possible. Learn more in the HubSpot CLI documentation.

App logs are now available in the HubSpot CLI

Developers can now retrieve app logs directly from the terminal using the new hs app logs CLI command. The command supports logs for serverless functions, CRM cards, webhooks, and API calls, with options to filter by app ID, log type, time range, and result limit. Developers can also use --json for structured output or --tail to continuously poll for new logs, making it easier to debug deployed apps and support agent-driven development workflows without switching to the UI. Learn more in the HubSpot CLI documentation.

Custom event timeline cards can now be customized

Users can now control how custom events appear on linked object record timelines, including the card header, subheader, visible properties, and property order. During custom event setup or editing, the new Customize timeline step lets teams use tokens to display real event values, choose which properties appear on the activity card, and preview the result in real time. This makes custom event activity easier to scan and understand without digging into raw event data. Learn more in the custom events documentation.

Content analytics and landing page creation now available in the Remote MCP server

Two new capabilities are live in HubSpot's remote MCP server: content analytics for standalone web assets and landing page creation. Previously, content analytics via MCP was limited to campaign-linked pages. That restriction is removed. You can now query performance data for any landing page, website page, or blog post, including views, form submissions, new contacts, bounce rate, CTA performance, and traffic sources.

Landing page creation is also available. Starting from an existing template or a clone of a page you already have, AI assistants can create, edit, and publish landing pages — including modifying copy, headlines, and CTAs; adding or reordering sections; making style changes; managing form embeds; and publishing (with an explicit confirmation step before the page goes live). Pages appear in your HubSpot account and are fully editable in the page editor. This release doesn't include bulk operations, custom module creation, A/B test setup, or first-time site/account setup.

For end-users using an agent or connector that uses the remote MCP server, if you've already connected HubSpot to an AI assistant, reconnect or re-authorize to grant the new permission scope. New connections prompt for it automatically. For setup details and a full list of available tools, see the HubSpot remote MCP server documentation.

Original source

The HubSpot Agent CLI is a new command-line interface purpose-built for AI agents to interact with your HubSpot CRM data — reading records, running searches, creating and updating objects, managing pipelines, properties, associations, workflows, and more. It's designed for agentic environments like Claude Cowork, Claude Code, and OpenAI Codex, and is particularly well-suited for scheduled automations, bulk operations, and background tasks that need to run without a human in the loop. The Agent CLI is now in public beta.

What's new?

The Agent CLI is a new binary, separate from the HubSpot CLI used for development. A few things worth understanding before you get started:

• It's built for agents. The Agent CLI is designed for AI agents to consume and use — not for developers to operate interactively. That said, you can run it yourself to test it or use it for custom scripting.
• It's separate from the HubSpot developer CLI. The developer CLI is for building and deploying HubSpot projects and themes. The Agent CLI has a separate command surface built for agent consumption. There's some functional overlap, but they serve different purposes and can be used together — for example, an agent could use the Agent CLI to populate mock data in a sandbox account or update production records as part of a developer-driven workflow.
• It doesn't replace the HubSpot MCP server (remote) or AI Connectors. The remote MCP server and AI Connectors remain the right choice for conversational, human-in-the-loop workflows — answering questions, pulling insights, and taking actions in real time from Claude, ChatGPT, and other chat environments. The Agent CLI complements them for the opposite scenario: repetitive, bulk, and scheduled work that runs in the background.
• For agent workflows specifically, a CLI offers practical advantages over MCP for certain use cases: CLI calls can be significantly more token-efficient (no full tool schema needs to be loaded into the agent's context window), there's no protocol negotiation overhead on each call, and commands can follow known terminal patterns — agents can filter, transform, and chain operations in a single step.

What the Agent CLI can do

Commands follow the pattern hubspot . Because the CLI is meant for agents to use, you don't need to really care about the commands themselves, but it helps to understand the capabilities. The current command surface covers:

• CRM objects: list, get, search, create, update, upsert, merge, and delete any object type (contacts, companies, deals, tickets, and custom objects), plus types to enumerate all available object types in the portal
• Pipelines: list, get, create, update, and delete pipelines and pipeline stages
• Properties: list, get, create, update, delete, and batch-manage properties across object types
• Associations: create, delete, and batch-manage associations between records, plus association label and limit management
• Owners: list HubSpot users (record owners)
• Custom object schemas: list, get, create, update, and delete schemas (requires admin mode — see below)
• Workflows: list, get, create, update, and delete workflows
• Activities: list activity history for a CRM record; fetch and delete call and meeting transcripts; list call dispositions; and fetch full email threads
• Reports: (Note: item left blank in original text)
• History: local audit log of all destructive operations run by the CLI

Output defaults to JSONL — a streaming, pipeable format where each line is a valid JSON object. Use --format json for a wrapped array with metadata, or --format table for a human-readable ASCII table.

Every write command supports a --dry-run flag that previews changes without applying them. Use it before running any mutation, especially against production accounts.

Authentication

The CLI supports two authentication modes:

• OAuth login: scoped to your HubSpot user-level permissions. Recommended for most agent workflows.
• Admin mode via service key: set a service key as HUBSPOT_ACCESS_TOKEN. Required for schema operations, most delete operations, reliable pipeline stage, and owner metadata resolution, and certain association types. Use with caution — this token carries broader permissions and doesn't generate a per-user audit trail.

Access control for admins

Super admins can use App Governance (beta) to control which users can connect the Agent CLI to a HubSpot account via OAuth. This doesn't restrict who can download the binary, but it does gate account-level data access. Learn more about managing access to apps.

If your organization uses Claude Team or Enterprise, your admin will also need to allowlist api.hubapi.com in Claude's network egress settings before the CLI can install or run from a Cowork session. Setup steps are covered in the Agent CLI guide.

For the full command reference, authentication details, piping examples, and output format documentation, see the Agent CLI guide.

When is it happening?

The HubSpot Agent CLI is now in public beta. To give it a try open your favorite agentic coding tool like Claude or Codex and paste the following prompt:

Install the HubSpot Agent CLI in this agent workspace. If this workspace uses a POSIX shell (macOS, Linux, WSL, or Bash), run curl -fsSL https://api.hubapi.com/hub/cli/backend/hub-cli/latest/install.sh | sh. If it uses Windows PowerShell, run irm https://api.hubapi.com/hub/cli/backend/hub-cli/latest/install.ps1 | iex. Then authenticate with hubspot auth login, install HubSpot Agent CLI Skills with npx skills add hubspot/agent-cli-skills, and use hubspot --help to explore what's available.

Questions or comments? Join us in the developer forums.

Original source

We’ve improved our SDK releases to support date-based API versioning, the new /YYYY-MM/ format introduced across HubSpot’s APIs. Generated from a centrally managed API specification, SDKs now cover more endpoints across multiple languages and release faster, so your clients stay aligned with the APIs you're building on.

The SDKs currently support the following languages:

• PHP
• Java
• Ruby
• Go
• TypeScript
• Python

Why does it matter?

Until now, gaps in SDK endpoint coverage meant you had to work around missing methods or rely on raw HTTP calls where a typed client would have been cleaner. With SDKs generated from a single, centrally managed spec, coverage expands significantly. Because the spec stays in sync with HubSpot's APIs as they evolve, you're less likely to encounter documentation drift or unexpected breaking changes. Updated packages are also distributed through standard package managers, so adopting new versions fits into your existing workflow.

How does it work?

The updated SDK packages are available through standard package managers, such as npm, so there are no changes that need to be made to your authentication setup or initialization.

To learn more about the updated SDKs, please check out the repositories.

Original source

We’ve improved our SDK releases to support date-based API versioning, the new /YYYY-MM/ format introduced across HubSpot’s APIs. Generated from a centrally managed API specification, SDKs now cover more endpoints across multiple languages and release faster, so your clients stay aligned with the APIs you're building on.

The SDKs currently support the following languages:

• PHP
• Java
• Ruby
• Go
• TypeScript
• Python

Why does it matter?

Until now, gaps in SDK endpoint coverage meant you had to work around missing methods or rely on raw HTTP calls where a typed client would have been cleaner. With SDKs generated from a single, centrally managed spec, coverage expands significantly. Because the spec stays in sync with HubSpot's APIs as they evolve, you're less likely to encounter documentation drift or unexpected breaking changes. Updated packages are also distributed through standard package managers, so adopting new versions fits into your existing workflow.

How does it work?

The updated SDK packages are available through standard package managers, such as npm, so there are no changes that need to be made to your authentication setup or initialization.

To learn more about the updated SDKs, please check out the repositories.

Original source

This month brings a set of updates aimed at making everyday building better. Breeze Assistant steps further into your workflows, a new useCrmSearch hook shipped for UI extensions, stage calculated properties available for custom objects and the HubSpot CLI got a fresh round of improvements — plus updates to blog author attribution, IP range webhooks, and more. Read on below for the details.

Create, update and test custom code workflow actions with Breeze Assistant

Breeze Assistant can now write, test, and iterate on custom code workflow actions. Describe what you want the action to do in plain language, and Breeze generates the full code — including input definitions, logic, and data outputs — ready for you to review, edit, and save. Previously, Breeze Assistant was limited to assembling workflows from HubSpot's standard actions or available third-party app actions.

To use it, open Breeze Assistant in Workflows and describe the action you want to build. You can specify your preferred language (defaults to JavaScript), which object properties to use as inputs, and expected outputs. Breeze generates the action, and you review it in the standard custom code editor before anything saves. Edit it directly to tune the logic, swap libraries, or adjust outputs.

A couple things to keep in mind: Secrets (API keys, tokens) are managed through the existing Manage secrets flow — Breeze references them by name in the code but never stores or sees the actual values. Testing from Breeze Assistant or the built-in test panel executes the action against a real record and can mutate it, just like using the standard Test flow in the UI.

No action required. This feature is now available for Data Hub Professional and Enterprise accounts.

New useCrmSearch Hook for UI Extensions

You can now use the new useCrmSearch React hook for UI extensions to search the CRM directly from app cards and app pages. You can now search, filter, and paginate across any CRM object type, including contacts, companies, deals, tickets, and custom objects, using free-text queries and structured filter groups, with built-in property formatting.

To use the hook, import it from the UI extension directory with import { useCrmSearch } from '@hubspot/ui-extensions' and pass a config object specifying the object type, properties to return and optional free-text queries and filter groups.

Learn more about the hook in our developer docs.

Blog Posts Can Now Be Attributed to Multiple Authors

You can now assign multiple authors to a single blog post for more accurate attribution. In the blog post settings, you can select multiple authors to attribute to a post.

Before assigning multiple authors to a single blog post, you must update the blog post templates to handle multiple authors. When using HubSpot’s default templates, assigned multiple authors will be displayed automatically.

To update your blog templates to feature multiple blog authors, use the HubL syntax content.blog_author_list. This will allow you to output a list of all authors associated with a specific blog post. From there, you can loop through the list of blog authors to display them on the post.

Example for loop:

{% set authors_to_display = content.blog_author_list if content.blog_author_list and content.blog_author_list|length > 0 else [content.blog_author] if content.blog_author else [] %}
{% if authors_to_display and authors_to_display|length > 0 %}
  <div class="blog-meta">
    <div class="blog-meta__avatars">
      {% for author in authors_to_display %}
        <div class="blog-meta__image-container">
          <img src="{{ author.avatar or get_asset_url('../images/avatar-placeholder.jpg') }}" alt="{{ author.display_name|escape_attr }}" width="48" height="48">
        </div>
      {% endfor %}
    </div>

    <div class="blog-meta__content">
      <div class="blog-meta__authors">
        {% for author in authors_to_display %}
          {% if author.display_name %}
            {{ author.display_name|sanitize_html }}{% if not loop.last %}{% if loop.revindex == 2 %}, and {% else %}, {% endif %}{% endif %}
          {% endif %}
        {% endfor %}
      </div>
    </div>
  </div>
{% endif %}

Stage Calculated Properties for Custom Objects

Custom objects can now have stage calculated properties that automatically track how records move through pipeline stages. These properties function the same way as the stage calculated properties that already exist for standard objects like tickets and deals.

See the product update for more details.

HubSpot IP Ranges Webhooks

Introducing webhook notifications for HubSpot IP range changes. Customers can now subscribe to receive notifications when HubSpot’s published IP ranges are added, modified, or removed, allowing them to proactively update their firewall rules and network configurations.

We previously announced email notifications for account admins. Now webhook notifications are available via the IP Ranges API. Customers can register a webhook endpoint to receive callbacks when IP ranges change.

See the documentation for more details.

Reminder: Legacy CRM Cards Deprecation for October 31, 2026

This is a reminder that support for legacy CRM cards built with the CRM Extensions API is being deprecated on October 31, 2026. This deprecation was originally announced on May 15, 2025.

What's changing?

Legacy CRM cards built with the legacy CRM Extensions API will no longer be supported on October 31, 2026. After that date, legacy CRM cards will no longer render in HubSpot CRM records. This does not affect UI Extensions built with Projects. Only legacy cards created via the legacy CRM Extensions API (/crm/v3/extensions/cards and related endpoints) are impacted.

Key dates and next steps:

• May 15, 2025: Deprecation originally announced
• October 31, 2026: Classic CRM cards stop rendering. The CRM Extensions API endpoints supporting classic cards will be removed.

To get ready:

• Audit any apps using the CRM Extensions API to identify classic CRM cards that need to be migrated.
• Rebuild impacted cards as UI Extensions and the Projects framework.
• Test migrated cards in a developer account before the October 31, 2026, deadline.

Helpful resources:

• App cards overview
• Migrate a legacy CRM card to an app card
  • Legacy CRM Card to UI Extension Converter
  • Migrating Legacy CRM Cards to App Cards Demo

Unformatted Number properties now support decimals

Users can now enter decimal values into CRM properties configured with the “Unformatted Number” field type. Previously, these properties only accepted whole numbers, which created limitations for use cases requiring more precise numeric values.

This update removes a key usability barrier and expands support for workflows and integrations that rely on decimal-based data.

HubSpot CLI updates: improve project uploads, account linking, and local development

Recent HubSpot CLI releases introduced several updates to make project development and deployment more reliable. Project uploads now support NPM workspaces, include stronger audit and ESLint validation, support --skip-npm-audit, and correctly return failed exit codes when build or deploy steps fail. The CLI also adds hs project app-install-status for checking app installation state, --use-env support for project commands, and custom local development ports with hs project dev --port.

Account management has also been improved with the new hs account link and hs account unlink commands, which let developers scope authenticated accounts to a specific directory. These releases also include expanded MCP tooling, clearer debug and command failure logs, improved project linting, updated “Content Hub” terminology, and fixes for sandbox creation timeouts, version reporting, CMS serverless function defaults, and multi-function project logs.

Upgrade the CLI with npm install -g @hubspot/cli and learn more in the HubSpot CLI commands overview.

HubSpot CLI introduces global authentication with directory-level account linking

The HubSpot CLI now uses a global authentication model with per-directory account linking, helping developers manage authenticated accounts from a single source of truth. Developers can authenticate accounts globally, then use hs account link to associate specific accounts with a project directory, set a local default with hs account default, view the active context with hs account current and remove linked accounts with hs account unlink.

This update reduces duplicated repo-local configuration and makes it clearer which account a project is using, helping prevent accidental deployments to the wrong account. Existing legacy .hsaccount files are migrated to the new .hs/settings.json format automatically where possible.

Learn more in the HubSpot CLI account commands reference.

Public Betas

Manage Stage Calculated Properties by Pipeline

Users can now control which pipelines and pipeline stages generate stage calculated properties (SCPs). By default, SCPs are disabled for new custom pipelines and stages but can be enabled anytime. Previously, SCPs were automatically created for every pipeline and stage, which could add hundreds or thousands of properties to an account whether they were needed or not. If your integration uses stage calculated properties, you will need to account for those properties not being created for all custom pipelines.

This feature is currently in public beta. See the product update for more details and to join the beta to test this feature.

Custom URL support in the telemetry component

The HubSpot telemetry component now supports routing data to a custom backend. Previously, telemetry export was limited to Sentry and Honeycomb. With this update, you can now direct app telemetry data to any backend you control.

To use it, follow the telemetry setup guide (https://developers.hubspot.com/docs/apps/developer-platform/add-features/add-telemetry) and set providerType to CUSTOM_BACKEND, then add an endpointUrl field pointing to your backend. HubSpot will forward your app's telemetry data to that endpoint.

This feature is available in public beta on the Developer Platform.

Questions or comments?

Please join us in our developer forums.

Original source

Create, update and test custom code workflow actions with Breeze Assistant

Breeze Assistant can now write, test, and iterate on custom code workflow actions. Describe what you want the action to do in plain language, and Breeze generates the full code — including input definitions, logic, and data outputs — ready for you to review, edit, and save. Previously, Breeze Assistant was limited to assembling workflows from HubSpot's standard actions or available third-party app actions.

To use it, open Breeze Assistant in Workflows and describe the action you want to build. You can specify your preferred language (defaults to JavaScript), which object properties to use as inputs, and expected outputs. Breeze generates the action, and you review it in the standard custom code editor before anything saves. Edit it directly to tune the logic, swap libraries, or adjust outputs.

A couple things to keep in mind: Secrets (API keys, tokens) are managed through the existing Manage secrets flow — Breeze references them by name in the code but never stores or sees the actual values. Testing from Breeze Assistant or the built-in test panel executes the action against a real record and can mutate it, just like using the standard Test flow in the UI.

No action required. This feature is now available for Data Hub Professional and Enterprise accounts.

New useCrmSearch Hook for UI Extensions

You can now use the new useCrmSearch React hook for UI extensions to search the CRM directly from app cards and app pages. You can now search, filter, and paginate across any CRM object type, including contacts, companies, deals, tickets, and custom objects, using free-text queries and structured filter groups, with built-in property formatting.

To use the hook, import it from the UI extension directory with import { useCrmSearch } from '@hubspot/ui-extensions' and pass a config object specifying the object type, properties to return and optional free-text queries and filter groups.

Learn more about the hook in our developer docs.

Blog Posts Can Now Be Attributed to Multiple Authors

You can now assign multiple authors to a single blog post for more accurate attribution. In the blog post settings, you can select multiple authors to attribute to a post.

Before assigning multiple authors to a single blog post, you must update the blog post templates to handle multiple authors. When using HubSpot’s default templates, assigned multiple authors will be displayed automatically.

To update your blog templates to feature multiple blog authors, use the HubL syntax content.blog_author_list. This will allow you to output a list of all authors associated with a specific blog post. From there, you can loop through the list of blog authors to display them on the post.

Example for loop:

{% set authors_to_display = content.blog_author_list if content.blog_author_list and content.blog_author_list|length > 0 else [content.blog_author] if content.blog_author else [] %}
{% if authors_to_display and authors_to_display|length > 0 %}
  <div class="blog-meta">
    <div class="blog-meta__avatars">
      {% for author in authors_to_display %}
        <div class="blog-meta__image-container">
          <img src="{{ author.avatar or get_asset_url('../images/avatar-placeholder.jpg') }}" alt="{{ author.display_name|escape_attr }}" width="48" height="48">
        </div>
      {% endfor %}
    </div>

    <div class="blog-meta__content">
      <div class="blog-meta__authors">
        {% for author in authors_to_display %}
          {% if author.display_name %}
            {{ author.display_name|sanitize_html }}{% if not loop.last %}{% if loop.revindex == 2 %}, and {% else %}, {% endif %}{% endif %}
          {% endif %}
        {% endfor %}
      </div>
    </div>
  </div>
{% endif %}

Stage Calculated Properties for Custom Objects

Custom objects can now have stage calculated properties that automatically track how records move through pipeline stages. These properties function the same way as the stage calculated properties that already exist for standard objects like tickets and deals.

See the product update for more details.

HubSpot IP Ranges Webhooks

Introducing webhook notifications for HubSpot IP range changes. Customers can now subscribe to receive notifications when HubSpot’s published IP ranges are added, modified, or removed, allowing them to proactively update their firewall rules and network configurations.

We previously announced email notifications for account admins. Now webhook notifications are available via the IP Ranges API. Customers can register a webhook endpoint to receive callbacks when IP ranges change.

See the documentation for more details.

Reminder: Legacy CRM Cards Deprecation for October 31, 2026

This is a reminder that support for legacy CRM cards built with the CRM Extensions API is being deprecated on October 31, 2026. This deprecation was originally announced on May 15, 2025.

What's changing?

Legacy CRM cards built with the legacy CRM Extensions API will no longer be supported on October 31, 2026. After that date, legacy CRM cards will no longer render in HubSpot CRM records. This does not affect UI Extensions built with Projects. Only legacy cards created via the legacy CRM Extensions API (/crm/v3/extensions/cards and related endpoints) are impacted.

Key dates and next steps:

• May 15, 2025: Deprecation originally announced
• October 31, 2026: Classic CRM cards stop rendering. The CRM Extensions API endpoints supporting classic cards will be removed.

To get ready:

• Audit any apps using the CRM Extensions API to identify classic CRM cards that need to be migrated.
• Rebuild impacted cards as UI Extensions and the Projects framework.
• Test migrated cards in a developer account before the October 31, 2026, deadline.

Helpful resources:

• App cards overview
• Migrate a legacy CRM card to an app card
  • Legacy CRM Card to UI Extension Converter
  • Migrating Legacy CRM Cards to App Cards Demo

Unformatted Number properties now support decimals

Users can now enter decimal values into CRM properties configured with the “Unformatted Number” field type. Previously, these properties only accepted whole numbers, which created limitations for use cases requiring more precise numeric values.

This update removes a key usability barrier and expands support for workflows and integrations that rely on decimal-based data.

HubSpot CLI updates: improve project uploads, account linking, and local development

Recent HubSpot CLI releases introduced several updates to make project development and deployment more reliable. Project uploads now support NPM workspaces, include stronger audit and ESLint validation, support --skip-npm-audit, and correctly return failed exit codes when build or deploy steps fail. The CLI also adds hs project app-install-status for checking app installation state, --use-env support for project commands, and custom local development ports with hs project dev --port.

Account management has also been improved with the new hs account link and hs account unlink commands, which let developers scope authenticated accounts to a specific directory. These releases also include expanded MCP tooling, clearer debug and command failure logs, improved project linting, updated “Content Hub” terminology, and fixes for sandbox creation timeouts, version reporting, CMS serverless function defaults, and multi-function project logs.

Upgrade the CLI with npm install -g @hubspot/cli and learn more in the HubSpot CLI commands overview.

HubSpot CLI introduces global authentication with directory-level account linking

The HubSpot CLI now uses a global authentication model with per-directory account linking, helping developers manage authenticated accounts from a single source of truth. Developers can authenticate accounts globally, then use hs account link to associate specific accounts with a project directory, set a local default with hs account default, view the active context with hs account current and remove linked accounts with hs account unlink.

This update reduces duplicated repo-local configuration and makes it clearer which account a project is using, helping prevent accidental deployments to the wrong account. Existing legacy .hsaccount files are migrated to the new .hs/settings.json format automatically where possible.

Learn more in the HubSpot CLI account commands reference.

Public Betas

Manage Stage Calculated Properties by Pipeline

Users can now control which pipelines and pipeline stages generate stage calculated properties (SCPs). By default, SCPs are disabled for new custom pipelines and stages but can be enabled anytime. Previously, SCPs were automatically created for every pipeline and stage, which could add hundreds or thousands of properties to an account whether they were needed or not. If your integration uses stage calculated properties, you will need to account for those properties not being created for all custom pipelines.

This feature is currently in public beta. See the product update for more details and to join the beta to test this feature.

Custom URL support in the telemetry component

The HubSpot telemetry component now supports routing data to a custom backend. Previously, telemetry export was limited to Sentry and Honeycomb. With this update, you can now direct app telemetry data to any backend you control.

To use it, follow the telemetry setup guide (https://developers.hubspot.com/docs/apps/developer-platform/add-features/add-telemetry) and set providerType to CUSTOM_BACKEND, then add an endpointUrl field pointing to your backend. HubSpot will forward your app's telemetry data to that endpoint.

This feature is available in public beta on the Developer Platform.

Questions or comments?

Please join us in our developer forums.

Original source

Beginning May 26, 2026, the ability to create new legacy public apps via the Developer Platform UI will be permanently disabled. New public app development should use the Projects-based app platform.

What's changing?

The Developer Platform UI will no longer allow the creation of new legacy public apps. The rollout occurs on two timelines based on account creation date:

• New accounts (created on or after May 26, 2026): Legacy public app creation is disabled as of May 26, 2026.
• Existing accounts (created before May 26, 2026): Legacy public app creation is disabled as of June 23, 2026.

Existing legacy public apps are not affected by this change. They will continue to function as-is. Existing or new legacy private apps are also not affected at this time. A separate migration initiative, with its own timeline and tooling, will address the migration of existing legacy public apps to the Projects-based platform.

How it works

To create apps intended for listing in the Marketplace, use the HubSpot CLI with Projects-based tooling. Project-based apps support CLI-based workflows, UI extensions, app cards, and dedicated deployment tooling. Follow the developer documentation to set up your environment and create your first project-based app.

Key dates and next steps:

• May 26, 2026: Legacy public app creation is disabled for all accounts created on or after this date.
• June 23, 2026: Legacy public app creation is disabled for all accounts created before May 26, 2026.

To get ready:

• If you are building a new app intended for the Marketplace, begin using the Projects-based platform now.
• Review the HubSpot CLI and Projects documentation to set up your development environment.
• No action is required to maintain existing legacy public apps — they continue to function without interruption.

Helpful resources:

• Projects-based app developer documentation
• HubSpot App Marketplace listing requirements
• Migration guide for existing legacy public apps

Questions or concerns?

Join us in the Developer Community Forum for a peer-to-peer discussion.

Original source

We're updating the requirements for listed and certified apps in the HubSpot Marketplace to align with current platform standards and deprecations. These updates ensure that apps stay compatible with HubSpot's evolving platform and APIs, providing customers with a more reliable, secure experience.

Unsupported developer platform + API versioning requirements

HubSpot releases a new version of its developer platform and REST APIs every 6 months (March and September). Each release includes a transition period before previous versions become unsupported. To ensure apps are built on supported, up-to-date platform versions:

• Use of supported versions: Apps must use a currently supported version of HubSpot’s developer platform and APIs (latest version recommended).
• Marketplace listings: New apps built on unsupported platform versions will be rejected from being listed
• Certification & recertification: Apps must be on a supported developer platform and API version at the time of review. A defined remediation window will be provided if updates are required.

Enforcement timeline:

• Starting November 2, 2026:
  • Apps must be on a supported developer platform version (v2025.2 or v2026.03).
  • Apps using legacy apps or Projects 2023.2 / 2025.1
    • will be rejected for new listings
    • Apps undergoing certification or recertification will have ~60 days to migrate to a supported version
• Starting March 2027:
  • v4 APIs will become unsupported
    • Apps undergoing certification or recertification will have ~60 days to migrate

Legacy CRM card deprecation requirements

Legacy CRM cards will be fully deprecated on October 31, 2026. To support this transition:

• Effective immediately, legacy CRM cards are no longer permitted for new app listings, certifications, or recertification submissions.
• If your app currently uses legacy CRM cards, you must migrate to app cards to be eligible.
• All other listed and certified apps must migrate by October 31, 2026.

Uninstall app endpoint usage requirement

For all new app certification submissions and apps undergoing recertification, your app must use the Uninstall App API endpoint:

DELETE /appinstalls/v3/external-install

This endpoint requires an active OAuth access token and fully removes your app from a customer's HubSpot account, including all associated features and webhooks. Upon a successful uninstall, super admins in the account will receive an email notification with a link to reinstall the app if needed.

Apps must use OAuth v3 endpoints

Effective immediately, all new app listings, certification submissions, and apps undergoing recertification, must use the new OAuth v3 endpoints.

OAuth v1 endpoints are being deprecated and will be replaced by the latest OAuth API endpoints, which are exposed in date-based versions:

• POST /oauth/2026-03/token - authorization code & refresh token exchange
• POST /oauth/2026-03/token/introspect - token introspection (access & refresh tokens)
• POST /oauth/2026-03/token/revoke - token revocation (refresh tokens)

Token access and storage security questionnaire

For certification and recertification, developers must now complete a security questionnaire*. This questionnaire will ask a series of questions regarding OAuth token access and storage. Key areas covered include: encryption, access controls, and token lifecycle management.

• The questionnaire extends beyond certification and will also be implemented for other programs, such as requesting access to sensitive data scopes.

Testing credentials no longer required for app listing

As of March 31, 2026, testing credentials no longer need to be provided for app listing submissions.

• This reduces partner effort and improves security by eliminating the need to share and store sensitive login information.
• Instead, demo videos or guided walkthroughs demonstrating core user flows, configuration, and permission usage should be provided.

See the updated marketplace listing requirements and certification requirements for more details.

If you have any questions or comments, please join the discussion in our community.

Original source

Unsupported developer platform + API versioning requirements

We're updating the requirements for listed and certified apps in the HubSpot Marketplace to align with current platform standards and deprecations. These updates ensure that apps stay compatible with HubSpot's evolving platform and APIs, providing customers with a more reliable, secure experience.

HubSpot releases a new version of its developer platform and REST APIs every 6 months (March and September). Each release includes a transition period before previous versions become unsupported. To ensure apps are built on supported, up-to-date platform versions:

• Use of supported versions: Apps must use a currently supported version of HubSpot’s developer platform and APIs (latest version recommended).
• Marketplace listings: New apps built on unsupported platform versions will be rejected from being listed
• Certification & recertification: Apps must be on a supported developer platform and API version at the time of review. A defined remediation window will be provided if updates are required.

Enforcement timeline:

• Starting November 2, 2026:
  • Apps must be on a supported developer platform version (v2025.2 or v2026.03).
  • Apps using legacy apps or Projects 2023.2 / 2025.1
    • will be rejected for new listings
    • Apps undergoing certification or recertification will have ~60 days to migrate to a supported version
• Starting March 2027:
  • v4 APIs will become unsupported
    • Apps undergoing certification or recertification will have ~60 days to migrate

Legacy CRM card deprecation requirements

Legacy CRM cards will be fully deprecated on October 31, 2026. To support this transition:

• Effective immediately, legacy CRM cards are no longer permitted for new app listings, certifications, or recertification submissions.
• If your app currently uses legacy CRM cards, you must migrate to app cards to be eligible.
• All other listed and certified apps must migrate by October 31, 2026.

Uninstall app endpoint usage requirement

For all new app certification submissions and apps undergoing recertification, your app must use the Uninstall App API endpoint:

DELETE /appinstalls/v3/external-install

This endpoint requires an active OAuth access token and fully removes your app from a customer's HubSpot account, including all associated features and webhooks. Upon a successful uninstall, super admins in the account will receive an email notification with a link to reinstall the app if needed.

Apps must use OAuth v3 endpoints

Effective immediately, all new app listings, certification submissions, and apps undergoing recertification, must use the new OAuth v3 endpoints.

OAuth v1 endpoints are being deprecated and will be replaced by the latest OAuth API endpoints, which are exposed in date-based versions:

• POST /oauth/2026-03/token - authorization code & refresh token exchange
• POST /oauth/2026-03/token/introspect - token introspection (access & refresh tokens)
• POST /oauth/2026-03/token/revoke - token revocation (refresh tokens)

Token access and storage security questionnaire

For certification and recertification, developers must now complete a security questionnaire*. This questionnaire will ask a series of questions regarding OAuth token access and storage. Key areas covered include: encryption, access controls, and token lifecycle management.

* The questionnaire extends beyond certification and will also be implemented for other programs, such as requesting access to sensitive data scopes.

Testing credentials no longer required for app listing

As of March 31, 2026, testing credentials no longer need to be provided for app listing submissions.

• This reduces partner effort and improves security by eliminating the need to share and store sensitive login information.
• Instead, demo videos or guided walkthroughs demonstrating core user flows, configuration, and permission usage should be provided.

See the updated marketplace listing requirements and certification requirements for more details.
If you have any questions or comments, please join the discussion in our community.

Original source

Legacy CRM Card Migration Tool Now Available

This month, on top of all the of the amazing updates and releases from Spring Spotlight 2026, we also have updates regarding the availability of our legacy CRM card migration tool, new features for the Custom Channels API, and more. Make sure to read on below for more details.

Starting April 21st, 2026, HubSpot introduced the Legacy CRM Card View Swapping Tool, which enables developers to migrate Legacy CRM Cards to UI Extension App Cards without disrupting existing customer CRM views.

Legacy CRM Cards are scheduled for deprecation on October 31st, 2026. Without migration, legacy CRM cards will eventually disappear from customer views that use them. The View Swapping Tool allows developers to proactively replace legacy cards with HubSpot’s newer App Cards while preserving existing view placements and minimizing customer impact.

The Legacy CRM Card View Swapping Tool is a developer-initiated migration workflow that:

• Replaces a legacy CRM card with a UI extension app card.
• Automatically updates existing customer CRM views.
• Requires no action from customers.
• Runs asynchronously across all app installs.

The migration with the swapping tool hides the legacy card and displays the replacement App Card in the same view locations.

What's changing?

New Capabilities

• A new migrate views API endpoint to replace legacy CRM cards with app cards in existing customer views.
• Support for the following view locations:
  • crm.record.sidebar
  • helpdesk.sidebar (explicitly required for ticket cards).
• Example App Cards, Postman Collection, and Figma design resources to accelerate migration.

Deprecation Reminder

Legacy CRM Cards will be fully deprecated on October 31st, 2026, and can no longer be created via the HubSpot UI.

Who Needs to Take Action

Developers should migrate if:

• Your app currently uses legacy CRM cards.
• Your app is installed in customer accounts where those cards appear in CRM views.
• You want to prevent customer-facing regressions when legacy cards are deprecated.

What does this mean for developers?

To begin migrating a legacy CRM card to an app card, follow the steps below or refer to this video demo.

Step 1: Prepare Your App

Upgrade to the latest HubSpot CLI version and connect to your HubSpot account:

npm i -g @hubspot/cli@latest
hs auth

Step 2: Migrate Your App

Ensure your Public (legacy) app is on the Projects Framework (Developer Platform version 2026.03+). If your app is not on the Project Framework, run:

hs app migrate

This migrates your app and existing legacy CRM cards without impacting customers.

Note: If you need additional references to migrate your app to the new framework, please refer to these guides:

• Migrate an existing public app to the projects framework

If your app is already project-based, run:

hs project migrate

Step 3: Create a Replacement App Card

Build a new UI extension app card to replace the legacy CRM card. There are two approaches depending on your goal:

• Option A: Redesign from scratch using the UI extension React components to take full advantage of the new framework’s capabilities. Figma resources are available for design support.
• Option B: Use the Legacy Card Converter for a quick migration that replicates your existing card’s behavior. Note that some differences apply, such as action requests using JSON instead of URL-encoded bodies and static card titles. See the README.md for more information.

Note: Develop and test App Cards in a separate testing app before deploying to production, as once view swapping has been initiated, it cannot be reversed.

Important migration notes

Ticket Support Considerations

If your legacy CRM card supports tickets, it’s important to note the following:

• Legacy cards automatically appear in the helpdesk.sidebar location.
• App cards do not.
• You must create two App Cards for each location, and each requires a unique title and extension card ID:
  • crm.record.sidebar
  • helpdesk.sidebar

Release the App Card

For migrated Marketplace apps:

• New app cards are hidden by default behind the hs-release-app-cards feature flag, which HubSpot auto-creates during migration and gates all app cards for each installed HubSpot account (you cannot gate individual cards).
• Use the hs-release-app-cards feature flag for testing and gradual rollout:
  • Turn it ON only for specific tests or beta portals by setting their portal-level flagState to ON while keeping other installs OFF.
  • To roll out to new installs only, batch-set all existing installs to OFF, then set the flag’s defaultState to ON so new installs automatically see app cards.
  • Expand access over time by switching additional portals to ON in batches until all installs are migrated.
• After rollout, delete the hs-release-app-cards feature flag so app cards are no longer gated.
• Before running the View Swapping Tool, confirm the flag has been deleted so replacement app cards are visible everywhere the migration will apply.

Note: To publish your app in the App Marketplace for the first time or to apply for certification if you already have a Marketplace-listed app, you must migrate and remove any legacy CRM cards and meet the Marketplace certification requirements and listing requirements.

Migrate Customer Views

Call the Migrate Views API once your replacement card is completed. Listed below are the required parameters:

• appId
• legacyCrmCardId
• appCardId
• helpdeskAppCardId (if applicable)
• Developer API key / OAuth token with sufficient permissions for the app.

This migration runs asynchronously across all installs. HubSpot will process the view updates asynchronously.

Example Response:

Migration Underway: X of X installs still processing

After the migration, the legacy CRM cards will no longer be visible and will be replaced by the app card. You can then safely remove the legacy card from your source code. If you do not remove it, the legacy CRM card will be automatically hidden from customers on October 31st, 2026, when the deprecation of legacy cards officially takes effect.

Note: End-user configuration is unnecessary. The existing card views will remain completely intact, ensuring that end-users experience no disruption, such as card loss or view resets, when your app card is implemented.

Standardized Memberships Error Messaging

Login failures for password-protected pages and memberships now return a single generic error message instead of multiple messages corresponding to the specific authentication issue.

What's changing?

Previously, Content Hub Professional and Content Hub Enterprise users could see different error messages depending on whether an email address existed or a password was incorrect. This created an inconsistent experience and could unintentionally expose account-related signals. This update improves security and delivers a more consistent login experience.

How it works

• All failed login attempts now return the same response, regardless of the underlying cause.
• Users will see a single message: “Invalid email or password.”
• No distinction is made between different authentication failures (e.g., incorrect email vs incorrect password)
• Existing login flows remain unchanged aside from this unified messaging.

This update is applied automatically, and no setup or migration is required.

Client Secret Rotation Now Available in Developer Platform UI

App owners can now rotate their app's client secret directly from the HubSpot developer platform UI with no support ticket required.

What's changing?

A new Rotate button now appears next to the client secret in the app's auth settings. Clicking it triggers a confirmation modal that requires you to type your app's name before proceeding. Once confirmed, the old secret is immediately invalidated, and a new one is generated.

Client secret rotation is available in:

• Legacy public apps: Developer portal > Auth tab
• Project-based apps: Projects > App Details > Client Credentials
• MCP Auth apps: MCP Connectors > Client Credentials

Why it matters

A leaked client secret can allow an attacker to create or generate OAuth tokens indefinitely. Previously, rotating a secret required opening a support ticket, a process that could take hours or days. This feature enables immediate, self-service response to security incidents.

Action required

No action is required at this time. If your app's client secret is compromised, you can now rotate it directly in your app's settings.

Custom Channels API: New sender and contact association options for outgoing messages

The Custom Channels API v2026-03 adds two new optional fields on outgoing messages: associateWithContactId and senderActorId. These fields give integrations more explicit control over which contact is linked to a thread and which actor is recorded as the sender of a message.

What's changing?

associateWithContactId

Channels using the CHANNEL_SPECIFIC_OPAQUE_ID delivery identifier type can now pass a HubSpot contact record ID when sending the first outgoing message of a thread via POST /conversations/custom-channels/2026-03/{channelId}/messages.

Example of associateWithContactId:

POST conversations/custom-channels/2026-03/123/messages
{
  "channelAccountId": 789,
  "messageDirection": "OUTGOING",
  "associateWithContactId": 54321
}

Constraints: only applies to CHANNEL_SPECIFIC_OPAQUE_ID channels; only takes effect on the first OUTGOING message of a thread; the contact ID is validated and must exist; requests on any other message type will be rejected. Channels using email or phone identifier types continue to resolve contact associations automatically.

senderActorId

All outgoing messages now accept an optional senderActorId field to record which actor (for example, a support rep, integration, or external chatbot) sent the message.

• Type: string
• Format: Conversations actor ID, such as:
  • A-12345 (HubSpot agent user)
  • I-67890 (integration)
• Scope: available across all delivery identifier types on outgoing messages.

When provided, senderActorId is used to attribute the message to that actor in Conversations (for example, which rep is shown as the sender). Example of a valid outgoing message with senderActorId:

POST conversations/custom-channels/2026-03/123/messages
{
  "channelAccountId": 789,
  "messageDirection": "OUTGOING",
  "text": "Hi from our support bot",
  "senders": [
    {
      "deliveryIdentifier": {
        "type": "CHANNEL_SPECIFIC_OPAQUE_ID",
        "value": "sender-opaque-id-123"
      },
      "name": "Support Bot",
      "senderActorId": "A-1234567"
    }
  ],
  "recipients": [
    {
      "deliveryIdentifier": {
        "type": "CHANNEL_SPECIFIC_OPAQUE_ID",
        "value": "recipient-opaque-id-456"
      }
    }
  ]
}

If senderActorId is missing, invalid, or used in the wrong context, the API returns HTTP 400 with a VALIDATION_ERROR response using the standard HubSpot error envelope. The most important cases are when using senderActorId on an INCOMING message. senderActorId is only allowed for outgoing messages. Including it on an INCOMING message will be rejected. Error example:

Personalized app and agent recommendations with Breeze Assistant

Users can now ask Breeze Assistant to recommend marketplace apps based on criteria entered, and refine the results with follow-up questions. Users can describe a business need in plain language and get pointed in the right direction, refining with follow-up questions until they land on the right fit, and find the right app faster and with confidence. See this product update for more details.

HubSpot CLI v8.4.0 Introduces Project Management Commands and UX Improvements

The latest HubSpot CLI version, 8.4.0, release adds two new commands, hs project info and hs project delete, enabling developers and AI agents to retrieve project metadata, generate install URLs, and delete apps directly from the CLI. The release also improves the developer experience with profile selection prompts when --profile is omitted and introduces an updated logging UI for supported terminals.

Several bugs have been addressed, including fixes for incorrect srcDir comparisons in hs project dev, improved profile error handling for 2025.1 projects, and issues affecting serverless function detection and local development.

For a complete list of available commands, check out the reference documentation.

Public Betas

Workflow action to change contact participant state for a marketing event

You can now automatically mark contacts’ participant state on manually created Marketing Events using a new workflow action.

With this workflow action, automatically mark contacts as:

• Registered
• Attended
• Canceled

Previously, businesses that relied on marketing events for lead generation and nurturing couldn't directly change contacts participation status for a marketing event. This update streamlines and automates that process. This workflow action is available for Pro+ customers. Learn more in the Product Update.

HubSpot IP Ranges Notifications

Introducing email notifications for HubSpot IP range changes. Customers can now subscribe to receive notifications when HubSpot’s published IP ranges are added, modified, or removed, allowing them to proactively update their firewall rules and network configurations.

Super admins can subscribe to email notifications via Settings → Notification Preferences → Security → IP Range Updates.

Questions or comments? Please join us in our developer forums.

Original source

This month, on top of all the of the amazing updates and releases from Spring Spotlight 2026, we also have updates regarding the availability of our legacy CRM card migration tool, new features for the Custom Channels API, and more. Make sure to read on below for more details.

Legacy CRM Card Migration Tool Now Available

Starting April 21st, 2026, HubSpot introduced the Legacy CRM Card View Swapping Tool, which enables developers to migrate Legacy CRM Cards to UI Extension App Cards without disrupting existing customer CRM views.

Legacy CRM Cards are scheduled for deprecation on October 31st, 2026. Without migration, legacy CRM cards will eventually disappear from customer views that use them. The View Swapping Tool allows developers to proactively replace legacy cards with HubSpot’s newer App Cards while preserving existing view placements and minimizing customer impact.

The Legacy CRM Card View Swapping Tool is a developer-initiated migration workflow that:

• Replaces a legacy CRM card with a UI extension app card.
• Automatically updates existing customer CRM views.
• Requires no action from customers.
• Runs asynchronously across all app installs.

The migration with the swapping tool hides the legacy card and displays the replacement App Card in the same view locations.

What's changing?

New Capabilities

• A new migrate views API endpoint to replace legacy CRM cards with app cards in existing customer views.
• Support for the following view locations:
  • crm.record.sidebar
  • helpdesk.sidebar (explicitly required for ticket cards).
• Example App Cards, Postman Collection, and Figma design resources to accelerate migration.

Deprecation Reminder

Legacy CRM Cards will be fully deprecated on October 31st, 2026, and can no longer be created via the HubSpot UI.

Who Needs to Take Action

Developers should migrate if:

• Your app currently uses legacy CRM cards.
• Your app is installed in customer accounts where those cards appear in CRM views.
• You want to prevent customer-facing regressions when legacy cards are deprecated.

What does this mean for developers?

To begin migrating a legacy CRM card to an app card, follow the steps below or refer to this video demo.

Step 1: Prepare Your App

Upgrade to the latest HubSpot CLI version and connect to your HubSpot account:

npm i -g @hubspot/cli@latest
hs auth

Step 2: Migrate Your App

Ensure your Public (legacy) app is on the Projects Framework (Developer Platform version 2026.03+). If your app is not on the Project Framework, run:

hs app migrate

This migrates your app and existing legacy CRM cards without impacting customers.

Note: If you need additional references to migrate your app to the new framework, please refer to these guides:

• Migrate an existing public app to the projects framework

If your app is already project-based, run:

hs project migrate

Step 3: Create a Replacement App Card

Build a new UI extension app card to replace the legacy CRM card. There are two approaches depending on your goal:

• Option A: Redesign from scratch using the UI extension React components to take full advantage of the new framework’s capabilities. Figma resources are available for design support.
• Option B: Use the Legacy Card Converter for a quick migration that replicates your existing card’s behavior. Note that some differences apply, such as action requests using JSON instead of URL-encoded bodies and static card titles. See the README.md for more information.

Note: Develop and test App Cards in a separate testing app before deploying to production, as once view swapping has been initiated, it cannot be reversed.

Important migration notes

Ticket Support Considerations

If your legacy CRM card supports tickets, it’s important to note the following:

• Legacy cards automatically appear in the helpdesk.sidebar location.
• App cards do not.
• You must create two App Cards for each location, and each requires a unique title and extension card ID:
  • crm.record.sidebar
  • helpdesk.sidebar

Release the App Card

For migrated Marketplace apps:

• New app cards are hidden by default behind the hs-release-app-cards feature flag, which HubSpot auto-creates during migration and gates all app cards for each installed HubSpot account (you cannot gate individual cards).
• Use the hs-release-app-cards feature flag for testing and gradual rollout:
  • Turn it ON only for specific tests or beta portals by setting their portal-level flagState to ON while keeping other installs OFF.
  • To roll out to new installs only, batch-set all existing installs to OFF, then set the flag’s defaultState to ON so new installs automatically see app cards.
  • Expand access over time by switching additional portals to ON in batches until all installs are migrated.
• After rollout, delete the hs-release-app-cards feature flag so app cards are no longer gated.
• Before running the View Swapping Tool, confirm the flag has been deleted so replacement app cards are visible everywhere the migration will apply.

Note: To publish your app in the App Marketplace for the first time or to apply for certification if you already have a Marketplace-listed app, you must migrate and remove any legacy CRM cards and meet the Marketplace certification requirements and listing requirements.

Migrate Customer Views

Call the Migrate Views API once your replacement card is completed. Listed below are the required parameters:

• appId
• legacyCrmCardId
• appCardId
• helpdeskAppCardId (if applicable)
• Developer API key / OAuth token with sufficient permissions for the app.

This migration runs asynchronously across all installs. HubSpot will process the view updates asynchronously.

Example Response:

Migration Underway: X of X installs still processing

After the migration, the legacy CRM cards will no longer be visible and will be replaced by the app card. You can then safely remove the legacy card from your source code. If you do not remove it, the legacy CRM card will be automatically hidden from customers on October 31st, 2026, when the deprecation of legacy cards officially takes effect.

Note: End-user configuration is unnecessary. The existing card views will remain completely intact, ensuring that end-users experience no disruption, such as card loss or view resets, when your app card is implemented.

Standardized Memberships Error Messaging

Login failures for password-protected pages and memberships now return a single generic error message instead of multiple messages corresponding to the specific authentication issue.

What's changing?

Previously, Content Hub Professional and Content Hub Enterprise users could see different error messages depending on whether an email address existed or a password was incorrect. This created an inconsistent experience and could unintentionally expose account-related signals. This update improves security and delivers a more consistent login experience.

How it works

• All failed login attempts now return the same response, regardless of the underlying cause.
• Users will see a single message: “Invalid email or password.”
• No distinction is made between different authentication failures (e.g., incorrect email vs incorrect password)
• Existing login flows remain unchanged aside from this unified messaging.

This update is applied automatically, and no setup or migration is required.

Client Secret Rotation Now Available in Developer Platform UI

App owners can now rotate their app's client secret directly from the HubSpot developer platform UI with no support ticket required.

What's changing?

A new Rotate button now appears next to the client secret in the app's auth settings. Clicking it triggers a confirmation modal that requires you to type your app's name before proceeding. Once confirmed, the old secret is immediately invalidated, and a new one is generated.

Client secret rotation is available in:

• Legacy public apps: Developer portal > Auth tab
• Project-based apps: Projects > App Details > Client Credentials
• MCP Auth apps: MCP Connectors > Client Credentials

Why it matters

A leaked client secret can allow an attacker to create or generate OAuth tokens indefinitely. Previously, rotating a secret required opening a support ticket, a process that could take hours or days. This feature enables immediate, self-service response to security incidents.

Action required

No action is required at this time. If your app's client secret is compromised, you can now rotate it directly in your app's settings.

Custom Channels API: New sender and contact association options for outgoing messages

The Custom Channels API v2026-03 adds two new optional fields on outgoing messages: associateWithContactId and senderActorId. These fields give integrations more explicit control over which contact is linked to a thread and which actor is recorded as the sender of a message.

What's changing?

associateWithContactId

Channels using the CHANNEL_SPECIFIC_OPAQUE_ID delivery identifier type can now pass a HubSpot contact record ID when sending the first outgoing message of a thread via POST /conversations/custom-channels/2026-03/{channelId}/messages.

Example of associateWithContactId:

POST conversations/custom-channels/2026-03/123/messages
{
  "channelAccountId": 789,
  "messageDirection": "OUTGOING",
  "associateWithContactId": 54321
}

Constraints: only applies to CHANNEL_SPECIFIC_OPAQUE_ID channels; only takes effect on the first OUTGOING message of a thread; the contact ID is validated and must exist; requests on any other message type will be rejected. Channels using email or phone identifier types continue to resolve contact associations automatically.

senderActorId

All outgoing messages now accept an optional senderActorId field to record which actor (for example, a support rep, integration, or external chatbot) sent the message.

• Type: string
• Format: Conversations actor ID, such as:
  • A-12345 (HubSpot agent user)
  • I-67890 (integration)
• Scope: available across all delivery identifier types on outgoing messages.

When provided, senderActorId is used to attribute the message to that actor in Conversations (for example, which rep is shown as the sender). Example of a valid outgoing message with senderActorId:

POST conversations/custom-channels/2026-03/123/messages
{
  "channelAccountId": 789,
  "messageDirection": "OUTGOING",
  "text": "Hi from our support bot",
  "senders": [
    {
      "deliveryIdentifier": {
        "type": "CHANNEL_SPECIFIC_OPAQUE_ID",
        "value": "sender-opaque-id-123"
      },
      "name": "Support Bot",
      "senderActorId": "A-1234567"
    }
  ],
  "recipients": [
    {
      "deliveryIdentifier": {
        "type": "CHANNEL_SPECIFIC_OPAQUE_ID",
        "value": "recipient-opaque-id-456"
      }
    }
  ]
}

If senderActorId is missing, invalid, or used in the wrong context, the API returns HTTP 400 with a VALIDATION_ERROR response using the standard HubSpot error envelope. The most important cases are when using senderActorId on an INCOMING message. senderActorId is only allowed for outgoing messages. Including it on an INCOMING message will be rejected.

Personalized app and agent recommendations with Breeze Assistant

Users can now ask Breeze Assistant to recommend marketplace apps based on criteria entered, and refine the results with follow-up questions. Users can describe a business need in plain language and get pointed in the right direction, refining with follow-up questions until they land on the right fit, and find the right app faster and with confidence. See this product update for more details.

HubSpot CLI v8.4.0 Introduces Project Management Commands and UX Improvements

The latest HubSpot CLI version, 8.4.0, release adds two new commands, hs project info and hs project delete, enabling developers and AI agents to retrieve project metadata, generate install URLs, and delete apps directly from the CLI. The release also improves the developer experience with profile selection prompts when --profile is omitted and introduces an updated logging UI for supported terminals.

Several bugs have been addressed, including fixes for incorrect srcDir comparisons in hs project dev, improved profile error handling for 2025.1 projects, and issues affecting serverless function detection and local development.

For a complete list of available commands, check out the reference documentation.

Public Betas

Workflow action to change contact participant state for a marketing event

You can now automatically mark contacts’ participant state on manually created Marketing Events using a new workflow action.

With this workflow action, automatically mark contacts as:

• Registered
• Attended
• Canceled

Previously, businesses that relied on marketing events for lead generation and nurturing couldn't directly change contacts participation status for a marketing event. This update streamlines and automates that process. This workflow action is available for Pro+ customers. Learn more in the Product Update.

HubSpot IP Ranges Notifications

Introducing email notifications for HubSpot IP range changes. Customers can now subscribe to receive notifications when HubSpot’s published IP ranges are added, modified, or removed, allowing them to proactively update their firewall rules and network configurations.

Super admins can subscribe to email notifications via Settings → Notification Preferences → Security → IP Range Updates.

Questions or comments? Please join us in our developer forums.

Original source

Beginning May 26, 2026, the ability to create new legacy public apps via the Developer Platform UI will be permanently disabled. New public app development should use the Projects-based app platform.

What's changing?

The Developer Platform UI will no longer allow the creation of new legacy public apps. The rollout occurs on two timelines based on account creation date:

• New accounts (created on or after May 26, 2026): Legacy public app creation is disabled as of May 26, 2026.
• Existing accounts (created before May 26, 2026): Legacy public app creation is disabled as of June 23, 2026.

Existing legacy public apps are not affected by this change. They will continue to function as-is. Existing or new legacy private apps are also not affected at this time. A separate migration initiative, with its own timeline and tooling, will address the migration of existing legacy public apps to the Projects-based platform.

How it works

To create apps intended for listing in the Marketplace, use the HubSpot CLI with Projects-based tooling. Project-based apps support CLI-based workflows, UI extensions, app cards, and dedicated deployment tooling. Follow the developer documentation to set up your environment and create your first project-based app.

Key dates and next steps:

• May 26, 2026: Legacy public app creation is disabled for all accounts created on or after this date.
• June 23, 2026: Legacy public app creation is disabled for all accounts created before May 26, 2026.

To get ready:

• If you are building a new app intended for the Marketplace, begin using the Projects-based platform now.
• Review the HubSpot CLI and Projects documentation to set up your development environment.
• No action is required to maintain existing legacy public apps — they continue to function without interruption.

Helpful resources:

• Projects-based app developer documentation
• HubSpot App Marketplace listing requirements
• Migration guide for existing legacy public apps

Questions or concerns?

Join us in the Developer Community Forum for a peer-to-peer discussion.

Original source

We’re making the Customer Agent Lead Status contact property hs_customer_agent_lead_status system‑managed and read‑only. This property stores Customer Agent system-generated lead qualification status on contact records (e.g., whether a contact was qualified, partially qualified or not qualified).

What’s changing

Starting July 13, 2026 HubSpot will enforce hs_customer_agent_lead_status as a read-only contact property:

• Only HubSpot-owned Customer Agent flows can update this field
• External writes from public APIs, integrations, workflows or manual updates will no longer be allowed
• Attempts to write to this property from outside Customer Agent will fail with an error

This change affects developers and integrations that include hs_customer_agent_lead_status in request bodies to CRM Objects APIs, set it via iPaaS tools (e.g., Make) or custom apps as part of your integration logic or use this field as a general-purpose lead status or as part of non–Customer Agent automation.

Note: Reading data from this property (e.g. in reports, lists or APIs) will continue to work. If you only consume this property as an output of Customer Agent for analytics or segmentation, no action is required.

What this means for developers

Before July 13, 2026:

1. Audit your usage: Search your API payloads, app code, workflow actions and integration for hs_customer_agent_lead_status. Check any middleware that updates contact properties during lead flows.

2. Redirect writing to the property: Create your own custom contact property for your integration’s lead status and update all API calls, workflows and integration configs to write to that property instead of hs_customer_agent_lead_status. If you need to mirror Customer Agent’s status into your own property, you can do so by reading hs_customer_agent_lead_status and writing the value into your custom field.

3. Test your changes: Confirm your integration no longer attempts to write to hs_customer_agent_lead_status and continues to function as expected.

Why is this changing?

Enforcing this property as read-only ensures that Customer Agent–driven lead qualification metrics accurately reflect product behavior from July 13, 2026 onward. In-app reporting and internal analytics using hs_customer_agent_lead_status are no longer skewed by unrelated external writes. Future improvements to Customer Agent lead qualification and reporting can safely treat this field as a trusted system signal.

If you have any questions or comments, join us in the Developer Forums to discuss this change in our community.

Original source

Welcome to the Spring Spotlight special edition of the developer changelog. We've got a lot of exciting updates to go over, including the general availability of date-based versioned APIs and Developer Platform version 2026.03. With these date-based updates comes a more stable release cadence. Both the APIs and Developer Platform project versions will have two major releases a year, in March and September. Additionally, to help you better prepare for these updates, we are also introducing an 18-month support cycle. Learn more about how date-based releases affect the Developer Platform on our developer documentation.

Developer Platform version 2026.03 now in General Availability

On March 30th, 2026, we released the HubSpot Developer Platform version 2026.03 for Projects, marking the first date-based platform version. This release reintroduced serverless functions to the Projects framework, formalizes an 18-month support lifecycle, and lays the groundwork for better alignment between the HubSpot Developer Platform, public APIs, and developer tooling.

If you’re currently building project-based private apps—especially those running on Projects version 2025.1—this release is your primary path to a modern platform with serverless support and predictable upgrade cadence.

What's changing?

Date-based platform version for Projects

Projects now support “platformVersion”: “2026.03” in hsprojects.json.

Each platform version follows a fix lifecycle:

• Current (6 months) - active maintenance, bug and security fixes.
• Supported (12 months) - critical fixes.
• After 18 months, versions become unsupported and are no longer updated; builds on unsupported versions will fail.

Serverless Functions on 2026.03

Platform version 2026.03 reintroduces serverless functions on the new Projects framework:

• Apps can define app functions using the updated *-hsmeta.json format (one function per file) instead of the single serverless.json file used in 2025.1, which was previously blocked from migrating to newer platform versions.

Agent tools on the Developer Platform

On the Developer Platform, you can build agent tools - enhanced custom workflow actions that HubSpot AI agents can call to perform tasks on behalf of users. Tools are implemented using the Developer Projects framework, submitted for review, and then made available to customers via your app listing and Breeze Agents.

Code Sharing for UI Extensions

You can now share code between UI extensions. Previously, if your App Cards, App Home Pages, and Settings pages required the same code types, utilities, and components, you had to copy the code for each instance. This meant that whenever you made updates, you had to revise every copy of that code separately.

New app listing & certification review updates

Staying on supported platform versions is now an expectation for listings and certifications. Marketplace apps that submit for listing/relisting or certification/recertification must run on a supported Developer Platform version (Projects 2025.2+ today, with 2026.03 as the recommended target), and certified apps must use a supported date-based API version. Additional app updates include:

• Classic legacy CRM cards must be migrated to App Cards by October 31, 2026. Effective immediately, legacy CRM cards are no longer permitted for new app listings, certifications, or recertifications. All listed or certified apps must migrate to App Cards or risk having their certifications revoked or delisted.
• Agent tools listing requirements for Marketplace apps. For apps that ship agent tools (like Breeze Agents can call), these tools are treated as a reviewable surface: they are built as enhanced custom workflow actions in a project. Marketplace-listed apps cannot deploy unapproved tools; deploys will fail until the tool passes review for compliance with the agent tool listing requirements.
• App Card Review Program reviews and approves CRM UI extension app cards submitted by Marketplace partners before they go live. Partners submit an intake form that includes their App ID, Build ID, and a video walkthrough, triggering an automated tracking ticket. A TPM reviews the video against four quality categories (security/privacy, performance/reliability, usability/accessibility, and value/functionality). Approval adds the app ID to the distribution list, and partners receive the Marketplace listing next steps.

Additionally, we’ll also be introducing a date-based version for APIs

Platform Projects version 2026.03 follows the same date-based naming convention as the public API date-based version /2026-03, improving clarity and consistency for developers building on HubSpot, without introducing technical dependencies between the platform and API date-based versions.

Key dates and next steps

• March 30th, 2026: Platform Projects version 2026.03 becomes generally available (first date-based platform version).
• August 1st, 2026: Projects version 2025.1 reaches the end of support; builds on 2025.1 will fail, and apps must move to 2025.2 or 2026.03 to stay supported.
• October 31st, 2026: Classic CRM cards sunset; apps must use App Cards on Projects 2025.2 or 2026.03 instead.

To get ready:

• Check your current platform version in the platformVersion field of hsproject.json, and plan your move to 2026.03 if you’re on 2025.1 or earlier.
• Review your UI extensions and migrate any classic CRM cards or legacy settings pages to App Cards, App Pages, and the new setting component model.
• If you build on the Marketplace, confirm your app is on the supported platform + API date-based version and review the App Card and agent tools listing requirements so you’re set up for future certifications and recertifications.

Helpful resources:

• Determine your migration path to 2026.03
• Serverless functions overview
• Agents and tools overview
• Share code between your extensions using npm workspaces
• Create an app card
• API versioning

Original source

Welcome to the Spring Spotlight special edition of the developer changelog.

We've got a lot of exciting updates to go over, including the general availability of date-based versioned APIs and Developer Platform version 2026.03. With these date-based updates comes a more stable release cadence. Both the APIs and Developer Platform project versions will have two major releases a year, in March and September. Additionally, to help you better prepare for these updates, we are also introducing an 18-month support cycle. Learn more about how date-based releases affect the Developer Platform

Developer Platform version 2026.03 now in General Availability

On March 30th, 2026, we released the HubSpot Developer Platform version 2026.03 for Projects, marking the first date-based platform version. This release reintroduced serverless functions to the Projects framework, formalizes an 18-month support lifecycle, and lays the groundwork for better alignment between the HubSpot Developer Platform, public APIs, and developer tooling.

If you’re currently building project-based private apps—especially those running on Projects version 2025.1—this release is your primary path to a modern platform with serverless support and predictable upgrade cadence.

What's changing?

Date-based platform version for Projects

Projects now support “platformVersion”: “2026.03” in hsprojects.json.

Each platform version follows a fix lifecycle:

• Current (6 months) - active maintenance, bug and security fixes.
• Supported (12 months) - critical fixes.
• After 18 months, versions become unsupported and are no longer updated; builds on unsupported versions will fail.

Serverless Functions on 2026.03

Platform version 2026.03 reintroduces serverless functions on the new Projects framework:

• Apps can define app functions using the updated *-hsmeta.json format (one function per file) instead of the single serverless.json file used in 2025.1, which was previously blocked from migrating to newer platform versions.

Agent tools on the Developer Platform

On the Developer Platform, you can build agent tools - enhanced custom workflow actions that HubSpot AI agents can call to perform tasks on behalf of users. Tools are implemented using the Developer Projects framework, submitted for review, and then made available to customers via your app listing and Breeze Agents.

Code Sharing for UI Extensions

You can now share code between UI extensions. Previously, if your App Cards, App Home Pages, and Settings pages required the same code types, utilities, and components, you had to copy the code for each instance. This meant that whenever you made updates, you had to revise every copy of that code separately.

New app listing & certification review updates

Staying on supported platform versions is now an expectation for listings and certifications. Marketplace apps that submit for listing/relisting or certification/recertification must run on a supported Developer Platform version (Projects 2025.2+ today, with 2026.03 as the recommended target), and certified apps must use a supported date-based API version. Additional app updates include:

• Classic legacy CRM cards must be migrated to App Cards by October 31, 2026. Effective immediately, legacy CRM cards are no longer permitted for new app listings, certifications, or recertifications. All listed or certified apps must migrate to App Cards or risk having their certifications revoked or delisted.
• Agent tools listing requirements for Marketplace apps. For apps that ship agent tools (like Breeze Agents can call), these tools are treated as a reviewable surface: they are built as enhanced custom workflow actions in a project. Marketplace-listed apps cannot deploy unapproved tools; deploys will fail until the tool passes review for compliance with the agent tool listing requirements.
• App Card Review Program reviews and approves CRM UI extension app cards submitted by Marketplace partners before they go live. Partners submit an intake form that includes their App ID, Build ID, and a video walkthrough, triggering an automated tracking ticket. A TPM reviews the video against four quality categories (security/privacy, performance/reliability, usability/accessibility, and value/functionality). Approval adds the app ID to the distribution list, and partners receive the Marketplace listing next steps.

Additionally, we’ll also be introducing a date-based version for APIs

Platform Projects version 2026.03 follows the same date-based naming convention as the public API date-based version /2026-03, improving clarity and consistency for developers building on HubSpot, without introducing technical dependencies between the platform and API date-based versions.

Key dates and next steps

• March 30th, 2026: Platform Projects version 2026.03 becomes generally available (first date-based platform version).
• August 1st, 2026: Projects version 2025.1 reaches the end of support; builds on 2025.1 will fail, and apps must move to 2025.2 or 2026.03 to stay supported.
• October 31st, 2026: Classic CRM cards sunset; apps must use App Cards on Projects 2025.2 or 2026.03 instead.

To get ready:

• Check your current platform version in the platformVersion field of hsproject.json, and plan your move to 2026.03 if you’re on 2025.1 or earlier.
• Review your UI extensions and migrate any classic CRM cards or legacy settings pages to App Cards, App Pages, and the new setting component model.
• If you build on the Marketplace, confirm your app is on the supported platform + API date-based version and review the App Card and agent tools listing requirements so you’re set up for future certifications and recertifications.

Helpful resources:

• Determine your migration path to 2026.03
• Serverless functions overview
• Agents and tools overview
• Share code between your extensions using npm workspaces
• Create an app card
• API versioning

Reintroducing Expanded Serverless Functions

Serverless Functions (App Functions) are back in the Developer Platform 2026.03. The Developer Platform 2026.03 release restores and expands the capabilities last seen in version 2025.1, aligning them with the unified Projects architecture introduced in 2025.02. A key update is expanded support for UI Extensions across App Settings and App Pages (formerly known as App Homes), including the ability to run and test functions in developer test accounts.

Availability and Access:

• App Functions (private)
  • Access: Requires an Enterprise subscription or a free developer test account.
  • Usage: Available within App Cards, App Pages, App Settings, and developer test accounts.
• Public Endpoint Functions
  • Access: Requires a Content Hub Enterprise subscription.
  • Usage: Public HTTP endpoints exposed via function configuration (for webhooks, public APIs, etc.).
  • Note: Public endpoints are not available in developer test accounts.

Functions can now run within Developer Test Accounts, enabling safer and more iterative development before production rollout.

How it Works:

• Upgrade to 2026.03: Ensure you are using CLI version 8.3.0 or higher, as the steps may vary based on your current version.
• From 2025.2: Update the platformVersion in your hsproject.json file from “2025.2” to “2026.03”, then run hs project upload.
• From 2023.0. 2023.2, or 2025.1: Run hs project migrate in your project directory and follow the prompts.
• Legacy public apps (non-project-based): Run hs app migrate and follow the prompts.
• Define your functions: Define serverless functions within your project directory, now aligning with the Projects 2025.2+ structure.
• Integrate with UI Extensions: Trigger these functions directly from the frontend code in App Settings and App Pages to handle custom data and enable user interactivity.
• Test in developer accounts: Deploy and validate your functions in a developer test account before deploying to production.

What's changing?

HubSpot offers multiple serverless function solutions depending on your use case:

Solution / Use Case / Access Level / Platform
2026.03 Serverless Functions — Modern project-based apps with UI Extensions — Private (App Functions) or Public (Endpoints) — HubSpot Projects
2025.1 Functions — Legacy project-based serverless functions — Private or Public — HubSpot Projects
CMS Serverless Functions — CMS Hub website functionality — Public endpoints only — CMS Hub

Key Differences:

• New configuration format: Uses -hsmeta.json files (e.g., myFunction-hsmeta.json) instead of a single serverless.json file. Each function has its own configuration file, improving validation and IDE support.
• Unified component model: Functions use the same Project schema as the other app components, making configuration more consistent across your app.
• Expanded UI Extension support: App Functions can be invoked from App Cards, App Pages, and App Settings, enabling richer in-app experiences powered by serverless logic.
• Simplified migration from 2025.2: If you’re already on 2025.2, moving to 2026.03 is primarily a version bump and reuse of the -hsmeta.json pattern your app already uses.

Configuration Examples:

Directory structure

Before (2025.1):

src/app/myFunctions.functions/
├── myFunction.js
└── serverless.json ← Single config for all functions

After (2026.03):

src/app/functions/
├── myFunction.js
├── myFunction-hsmeta.json ← Individual config per function
└── package.json

Configuration Schema

Before (2025.1):

{"runtime":"nodejs18.x","version":"1.0","functions":{"myFunction":{"file":"myFunction.js","secrets":["my_api_key"]}}}

After (2026.03):

{"uid":"myFunction","type":"app-function","config":{"entrypoint":"/app/functions/myFunction.js","secretKeys":["my_api_key"]}}

Functions are now configured and located in a single src/app/functions/ directory. This replaces the previous structure that used nested .functions folders. For complete migration steps, including updates from 2025.1 to 2025.2, please refer to the detailed guides in HubSpot’s Developer Documentation.

The 2026.03 version is now available. Developers can start building apps on 2026.03 or migrate eligible 2025.2, 2025.1, and 2023.3 projects to 2026.03.

Introducing a Modern API infrastructure: Date-based Versioned APIs

The first date-based API version, /2026-03/, is now available. Date-based versioning APIs from /2026-03/ onward use a /YYYY-MM/ format to clearly indicate the year and month they went live.

Why does it matter?

For included APIs, date-based versioning brings clearer expectations around timing of change with consistent windows for updates and support.

• Plan with confidence — breaking changes to supported APIs occur twice a year (March and September), with 18 months of support for each version.
• Reduce maintenance overhead — immutable API versions in /2026-03/ mean your supported APIs won't lead your integration to break unexpectedly within an API's support window, and you can migrate to newer versions on your own timeline.
• Navigate APIs more easily — Before, v1, v2, v3, v4 denoted versions of APIs. With date-based versioning, APIs from /2026-03/ onward will use a /YYYY-MM/ format to clearly indicate the year and month they went live.

How does it work?

Each version moves through three stages: Current (actively maintained, first 6 months), Supported (critical fixes to maintain stability and security, months 6–18), and Unsupported (no further updates after 18 months). Please note, HubSpot teams will continue to release enhancements via Public Betas throughout the year.

You can see which APIs are included in date-based versioning /2026-03/ here and HubSpot’s release schedule here.

Updates to the Webhooks Journal API

This release introduces several new capabilities to the Webhooks Journal API, including batched reads for higher-throughput journal processing, CRM object filtering on subscriptions to reduce event noise, list membership subscriptions for real-time list-change tracking, and a snapshot status polling endpoint to monitor asynchronous snapshot processing.

Webhooks Journal CRM Object Filtering (New)

The Webhooks Journal API now supports CRM-style object filtering on subscriptions, letting you define filter criteria (similar to CRM Search filters) that are evaluated against each journal event. Only events whose CRM object data matches your filters are written to the journal for that subscription.

This change reduces noise, bandwidth, and processing. It’s a push-based alternative to polling CRM APIs with the same filters, keeping your event selection logic centralized in subscription definitions rather than scattered across custom polling code.

Subscription Type for List Membership (New)

LIST_MEMBERSHIP subscriptionType lets your app receive your journal events whenever records enter or leave HubSpot lists, rather than polling the Lists API or inferring membership from property changes.

Webhooks v4 Batched Reads with Journal API (New)

The Webhooks Journal API now supports batched reads, allowing integrators to pull multiple journal entries in a single API call, significantly improving throughput for high-volume event streams and reducing per-entry request overhead.

Previously, the Webhooks Journal API required stepping through entries sequentially, meaning integrators had to make an API call for each journal entry URL and use a single “reader” process to advance the offset, which became a bottleneck at scale.

With this update, the Webhooks Journal API now lets you request multiple journal entries at once. Preserving the journal’s chronological, offset-based model while reducing the number of network round-trips required to stay caught up with event volume.

Batch Endpoints:

• Batch Read by offset: POST /webhooks/v4/journal/batch/read
• Batch Next (range from offset): GET webhooks/v4/journal/batch/{offset}/next/{count}
• Batch Fetch Earliest Entries: GET /webhooks/v4/journal/batch/earliest/{count}
• Batch Fetch Latest Entries: GET /webhooks/v4/journal/batch/latest/{count}

Note: Maximum batch size is 100 entries (journal batch operations), and exceeding the limit returns a 400 Bad Request error.

Snapshot Status Polling Endpoint (New)

You can now check the processing status of CRM object snapshots using a new polling endpoint. You can track whether a snapshot is still being processed, has completed successfully, or has failed. Each snapshot creation response now returns a snapshotStatusId that you can use to poll for updates until the snapshot reaches a terminal state.

Snapshot Endpoints:

• Create Snapshots: POST /webhooks/v4/snapshots/crm
• Check Snapshot Status: GET /webhooks/v4/snapshots/status/{statusId}

Note: 404’s are expected after creation. Status records are created asynchronously. This does not mean the snapshot failed - retry with backoff. Additionally, use an exponential backoff. Start at 1 second, cap at 30 seconds, and enforce a max polling direction (e.g., 10 minutes or 20 attempts) to avoid infinite loops.

For additional details on how to use the API, please refer to the developer documentation.

HubSpot MCP Server (remote) and Developer MCP Server (local) now in General Availability

The HubSpot MCP server (remote) is now generally available, enabling connecting agentic tools to your HubSpot account, and it includes expanded access. The HubSpot MCP server now has read-only access to campaigns, landing pages, website pages, blog posts. The HubSpot MCP server also has write access to CRM objects, meaning you can make updates to your CRM data through natural language.

Developers can use the HubSpot MCP server with AI APIs to build custom agentic workflows that leverage HubSpot data by building MCP auth apps.

The Developer MCP server (local) is also generally available, giving you the power to create HubSpot apps using natural language. You can download it through the HubSpot CLI and start chatting with it in your preferred AI-powered code editor, like Claude Code or Cursor. Run the command hs mcp setup to get started. You must be on the HubSpot CLI version 8.2.0 or higher to use the Developer MCP server. To check which version of the HubSpot CLI you're using, you can run the command hs --version.

The Developer MCP server has access to tools such as searching the developer documentaiton, creating new projects, and validating code before uploading to your account. See the table below for more info on the tools available:

Tool / Description
add-feature-to-project — Add a feature to an existing project
create-cms-function — Create a CMS serverless function
create-cms-module — Create a CMS module
create-cms-template — Create a CMS template
create-project — Create a new HubSpot project
create-test-account — Create a test account
deploy-project — Deploy a project
fetch-doc — Fetch documentation
get-api-usage-patterns-by-app-id — Get API usage patterns for an app
get-apps-info — Get apps information
get-build-logs — Get build logs
get-build-status — Get build status
get-cms-serverless-function-logs — Get CMS serverless function logs
get-feature-config-schema — Get feature config schema
guided-walkthrough-cli — Guided CLI walkthrough
list-cms-remote-contents — List CMS remote contents
list-cms-serverless-functions — List CMS serverless functions
search-docs — Search documentation
upload-project — Upload a project
validate-project — Validate a project

Expanding App Homes into App Pages, a Multi-page, Custom App Experience

App pages for UI extensions allows you to build custom, full-page experiences for your app directly within HubSpot using React. Starting with a dedicated app home as your app's landing page, app pages expand from there, letting you build as many additional pages as your app needs. Powered by UI extensions, these pages share the same toolkit as app cards and settings pages, allowing for a unified development approach that includes dedicated header actions, multi-page navigation, and seamless data fetching.

This feature fills a critical gap by providing a central home base for your app within HubSpot, eliminating the friction of sending users to external sites for dashboards, documentation, or configurations. App pages empowers developers to build a native-feeling, multi-page experience that improves user retention and gives users a dedicated, organized space for everything from high-level app interactions and reporting to onboarding flows and support resources.

Developers can get started by running hs project add in the CLI and selecting "Pages" to generate the necessary React and configuration files for their app pages. Additional pages can be added alongside it, with built-in PageRoutes and PageLink components handling navigation between them. You can build each interface using standard UI components and the PageHeader wrapper for primary and secondary page actions. Once deployed, users access app pages by clicking the Marketplace icon and selecting your app from "Recently visited apps" or via a direct app URL.

Keep your HubSpot Projects code DRY with code sharing

You can now share code across multiple UI extensions, app cards, settings pages, and app pages, within a single project using npm workspaces. You can create shared packages for utilities, types and components once, then import them into any extension in your project. With shared code, you can fix bugs in a single place, keeping things consistent between all pieces of your projects.

npm workspaces let you define shared packages for utilities, types, components or anything else alongside your extensions within the same project. Each extension can declare those shared packages as dependencies and import from them directly, just like any other package. Shared packages are installed automatically when you run hs project dev or hs project upload, or you can install them manually with hs project install-deps.

Technology Partner Program: Discover Your Tier in the New Dashboard

A new Technology Partner dashboard is now available in the Developer Platform, giving you an in-product view of your status in HubSpot's Technology Partner Program. From one place, you can see your current tier (Partner, Rising, Leading or Premier), what that tier unlocks, high-level requirements to maintain or advance and links to program resources and contacts.

Progress indicators show how close you are to the next tier based on key performance signals, refreshed approximately once per month. Tier badges also appear on your Marketplace app listing page and in Marketplace filters for Rising, Leading and Premier partners.

Public Betas

Connect the HubSpot MCP Server Securely with MCP Auth Apps

You can now build and manage your own AI connectors to the HubSpot MCP Server using a new self-service MCP Auth Apps tool in the Developer Platform. This update removes the need for general-purpose app tooling; it enables full lifecycle management of MCP connectors, including creation, configuration, and secure OAuth 2.1 credential access, all within a dedicated interface. End-user permissions are now handled automatically, giving customers more control over the data shared through MCP connections.

New App Install Governance Tool for Admins

Super Admins now have centralized control over which apps can be installed in their HubSpot account and what data can be shared with them — including controls over AI connectors like the HubSpot connectors for ChatGPT, Claude and Gemini.

With this public beta, admins can approve which apps are allowed, control which users can install each app, customize optional data permissions (such as read-only vs. write access) and revoke approval at any time.

Users who want access to an unapproved app can submit a request directly from within HubSpot for Super Admin review. Manage everything from Settings > Integrations > Connected Apps under the Manage Apps tab. Available across all hubs and tiers.

Learn more about managing app access

Original source