Hubspot Developers Updates & Release Notes

August’s developer updates expand how teams bring data into HubSpot and automate CRM operations. This month introduces webhook data sources for Data Studio, preserves active workflow enrollments when records are merged, and adds app object support to association workflow actions. Together, these changes reduce custom integration work and help automations continue with less manual intervention.

Join the discussion in the Developer Community.

• Stream JSON data into Data Studio with webhook data sources
• Primary records remain enrolled in workflows after merges
• Manage app object associations with workflows

Stream JSON data into Data Studio with webhook data sources

Developers and app partners can now send real-time JSON data from any HTTP-capable system directly into HubSpot Data Studio, without file uploads or a custom connector. Each source provides a unique inbound URL and supports GET, POST, and PUT requests, with options to create records or update existing records using a match key. Requests are currently limited to one record each, and the inbound URL should be treated as a secret because it is the source’s only authentication mechanism. Once ingested, the data can be used in datasets, segments, workflows, and reports; learn more about building and activating datasets in Data Studio.

Primary records remain enrolled in workflows after merges

When two CRM records are merged, the primary record will remain enrolled in its active workflows, preserving its current position, delays, branches, and pending actions. Only the duplicate record being merged away will be unenrolled, allowing data cleanup without interrupting in-flight automation. This change applies automatically to all CRM object types that support merging, and no action is required. Learn more about merging records in HubSpot.

Manage app object associations with workflows

The Manage CRM record associations workflow action now supports app objects from connected apps, allowing workflows to create, update, or remove associations between app object records and other CRM records. This eliminates manual linking and custom automation while making it easier to incorporate app data into existing pipeline, attribution, segmentation, and reporting processes.

What's Changing

HubSpot is permanently removing the ability to create new legacy, non-Project based, private apps through the account UI. Users needing similar functionality should use Service Keys, available via Developer Platform Projects version 2026.09 or later, which supports system-to-system integrations. This sunset impacts customer accounts on two timelines based on their age. All existing legacy private apps are not affected at this time.

Starting in late September 2026, the option to create new legacy private apps will be removed from the HubSpot account UI. The rollout is tiered by account age:

• New HubSpot accounts (created on or after September 28, 2026): Legacy private app creation is disabled on September 28, 2026
• Existing HubSpot accounts (created before September 28, 2026): Legacy private app creation is disabled on October 26, 2026

What is not changing:

All existing legacy private apps continue to work as-is. This change only removes the ability to create new ones. Now is your chance to get ahead and migrate existing legacy private apps to the Developer Platform Projects framework. Build on a more modern foundation and be ready for what’s next.

For any new in-account API integration, use Service Keys, HubSpot's modern authentication solution now available. Create a Service Key at Settings > Integrations > Service Keys.

Service Keys provide:

• Scoped access: grant only the permissions your integration needs
• Built-in activity logging: audit trails out of the box
• Easy key rotation: 7-day grace period for safe credential rollover
• Admin-only key visibility: key values restricted to admins by default

For integrations that require the use of webhooks, please see our “Create an app” guide for more information about how to use our new platform tools to support this use case.

When is it happening?

This change goes into effect on September 28, 2026 for accounts created on or after that date, and on October 26, 2026 for accounts created before that date.

Questions or comments? Join us in the developer forums.

Node 18.x and 20.x are being deprecated as supported runtimes for Chatflows custom code snippets. If you have bot code snippets running on either of these versions, you need to upgrade them to Node 24.x before August 31st, 2026, or you will lose the ability to edit those snippets until the upgrade is completed.

What's Changing

Node 18.x and 20.x have reached end of life and no longer receive security patches. To keep Chatflows custom code snippets on a secure, maintained foundation, HubSpot is deprecating support for these runtimes in favor of Node 24.x, the current long-term support (LTS) release.

To make upgrading easier, you can now change the Node.js runtime version of an existing bot code snippet in-place, without deleting and recreating the snippet. In the bot snippet editor, look for the option to change the runtime version. Your code, environment variables, and configuration are preserved through the switch. This capability is rolling out gradually over the next 2 weeks.

After August 31st, 2026, any snippet still running on Node 18.x or 20.x will become read-only. You won't be able to edit it until you upgrade the runtime to a supported version.

When Is It Happening?

Upgrade your Chatflow bot code snippets to Node 24.x before August 31st, 2026. After that date, snippets on unsupported runtimes will be locked from editing until upgraded. The in-place runtime switching feature is rolling out to Data Hub Professional and Enterprise customers now.

Questions or comments? Join us in the developer forums.

Starting with the /2026-09/ API version shipping on September 8, 2026, HubSpot will enforce admin-configured validation rules on all CRM API write paths. If your integration creates or updates CRM records, please make sure that it conforms to the below changes before updating your version of the API.

What's Changing

When a HubSpot admin configures rules governing how records are created or modified (conditional required properties, required fields on the Create Record form, or user-level association permissions), those rules will now apply to API writes, not just actions taken in the HubSpot UI. While this is a breaking change in that you will get error messages, these changes exist to help your app avoid making changes that violate HubSpot user's expectations which could put their data into strange states that run contrary to their rules.

Three behaviors are being enforced:

Conditional required properties. If an admin has configured a rule that makes a property required when another property has a specific value (for example, close_date becomes required when dealstage is set to closedwon), the API will return a 400 validation error if that property is missing on write. Previously, these rules were UI-only and the API ignored them.

//Example of an error

{
  "category": "VALIDATION_ERROR",
  "message": "...",
  "errors": [
    {
      "code": "MISSING_CONDITIONAL_REQUIRED_PROPERTY",
      "message": "my_property is required because of a conditional property rule based on [country]",
      "context": {
        "propertyName": [
          "my_property"
        ]
      }
    }
  ]
}

Record creator settings. If an admin has marked specific properties or associations as required at record creation time in Settings → Objects → [Object Type] → Create Record, the API will enforce those requirements on POST calls.

//Example of an error

{
  "status": "error",
  "category": "VALIDATION_ERROR",
  "message": "The property values provided are invalid",
  "errors": [
    {
      "code": "MISSING_REQUIRED_PROPERTY",
      "message": "A value for firstname must be provided",
      "context": {
        "propertyName": [
          "firstname"
        ]
      }
    }
  ]
}

Edit Associations permission. If your app uses user-level OAuth and the installing user does not have the "Edit Associations" permission (CRM_ASSOCIATIONS_WRITE_ACCESS scope), API calls that create, update, or delete associations will return an error. This does not affect portal-level app tokens.

//Example of an error

{
  "status": "error",
  "message": "Missing 'Edit Associations' permission.",
  "category": "VALIDATION_ERROR"
}

These behaviors only apply when an admin has actively configured these rules on a portal. If no conditional required property rules, record creator requirements, or association permission restrictions exist on a portal, there is no behavior change.

How to prepare

1. Suggest users of your integration to review the account your app writes to. Check Settings → Properties for conditional required rules, Settings → Objects → [Object] → Create Record for required field settings, and Settings → Users & Teams to confirm your app's installing user has the appropriate permissions.
2. Fetch current property definitions via GET /crm/{version}/properties/{objectType} to identify required fields before your write calls.
3. Ensure your write calls include all conditionally required properties when the controlling property value is set.
4. Ensure POST calls to create records include all properties and associations marked as required in Create Record settings.
5. If your app uses user-level OAuth, confirm the installing user has "Edit Associations" enabled, or remove association writes from your app's scope if not needed.

Handling validation errors

When enforcement is active, API write calls may return 400 Bad Request if the request violates an admin-configured rule. These errors indicate that the portal's configuration requires something your request didn't include, not necessarily a problem with your integration's logic.

• Parse the error message. Each violation returns a specific message identifying the rule that was violated (e.g., "Property 'close_date' is required when 'dealstage' is set to 'closedwon'." or "Missing 'Edit Associations' permission.").
• Re-check portal configuration. The rule may have been added or changed by an admin after your integration was last configured. Poll GET /crm/v3/properties/{objectType} to detect changes to required fields.
• Retry with corrected input. Adjust your request to satisfy the rule and retry. Do not retry the same request unchanged.
• Surface actionable errors to your users. Translate the validation message into guidance they can act on (e.g., "This portal requires a Close Date when Deal Stage is Closed Won").

Datetime validation improvements

The CRM API now handles datetime property inputs more permissively. Previously, valid inputs like off-midnight date values, ISO-8601 strings, or epoch-second timestamps could be rejected with errors like INVALID_DATE or cryptic range messages. The API now normalizes these inputs and returns a successful response with a new warnings array on the response object that describes any normalization that occurred. Error messages for genuine failures have also been improved to include the raw input, the parsed interpretation, and which constraint was violated.

If you want to surface normalization notices to users, read the warnings field from write responses. If your integration is expecting a certain shape to the error message, confirm that it is updated to this new shape.

//Example

{
  "category": "PROPERTY_VALUE_NORMALIZED",
  "context": {
    "normalizedValue": "631152000000",
    "propertyName": "date_of_birth",
    "rawValue": "1990-01-01T00:00:00Z"
  },
  "message": "date_of_birth was normalized"
}

When is it happening?

Enforcement goes into effect on September 8, 2026, with the release of the /2026-09/ API version. To learn more about HubSpot's date-based API versioning and how to migrate, see the Date-Based Versioning guide.

Questions or comments?

Join us in the developer forums.

Increase owner property limit to 250

HubSpot now supports up to 250 owner properties per object type, up from the previous limit of 50. This gives teams with more complex assignment and ownership tracking needs more flexibility without requiring support requests or workarounds.

Increase Webhooks Journal batch size to 10,000 records

HubSpot is increasing the Webhooks Journal batch size from batches of 100 records per S3 file to up to 10,000 or 5MB (whichever comes first). This increase is specific to the number of journal events contained within the returned S3 Presigned URL. This will increase speed efficiency when working with the Webhooks Journal.

This update will not affect the Webhooks Journal API limits.

Historical API Usage Chart

Historical API Usage is now available in Connected apps, giving customers a clearer view of where their API calls are coming from across apps and connectors. In Connected apps > Connection insights > API Call Usage, teams can review historical usage trends to better understand activity patterns, plan ahead, and make adjustments as needed.

Public betas

Contract Imports

Contract Imports is now in public beta, allowing customers to bring active contracts from external systems into HubSpot using the import tool. Customers can upload contract data by CSV, including key contract properties, contacts, line items, and deal associations, then manage those imported contracts in HubSpot with the same workflows used for contracts created natively, including change quotes and renewal quotes.

See the Contract Imports product update for more details and to join the beta to test this feature.

Payment Links API

You can now programmatically create, retrieve, and manage HubSpot Payment Links via the API, including support for dynamic multi-item carts and custom configurations. The Payment Links API beta has the following endpoints:

• POST /commerce/payment-links/2026-09-beta/payment-links
• GET /commerce/payment-links/2026-09-beta/payment-links/{paymentLinkId}
• GET /commerce/payment-links/2026-09-beta/payment-links
• PATCH /commerce/payment-links/2026-09-beta/payment-links/{paymentLinkId}
• DELETE /commerce/payment-links/2026-09-beta/payment-links/{paymentLinkId}

To learn more about these endpoints, check out the developer documentation.

Questions or comments? Join us in the developer forums.

7/23/2026 Edit

The post has been updated to include the Deal object specific validateDealStageUsagesBeforeDelete query parameter.

Availability: This is a breaking change for the next GA date-based API version, /2026-09/. It does not change the behavior of the current GA API version or earlier versions. Integrations will see this behavior only after moving to /2026-09/ or later.

Learn more about HubSpot's Date Based Versioning

What is changing?

Starting in version /2026-09/ of the Pipelines API, HubSpot will validate references before deleting a pipeline or pipeline stage. If the pipeline or stage is in use, the delete request will be blocked and return a validation error.

This makes public API deletes behave the same way as deletes from the pipeline settings page in HubSpot, where deleting a pipeline or stage is already blocked when it is in use.

The reference check is enabled by default because validateReferencesBeforeDelete and validateDealStageUsagesBeforeDelete will default to true in /2026-09/.

validateDealStageUsagesBeforeDelete is used for the Deal object and validateReferencesBeforeDelete for all other object types.

To bypass this validation, pass:

validateReferencesBeforeDelete=false
validateDealStageUsageBeforeDelete=false

Affected endpoints

• DELETE /crm/pipelines/{version}/{objectType}/{pipelineId}
• DELETE /crm/pipelines/{version}/{objectType}/{pipelineId}/stages/{stageId}
• PATCH /crm/pipelines/[version]/({objectType})/({pipelineId})
• PUT /crm/pipelines/[version]/({objectType})/({pipelineId})

This change applies when {version} is /2026-09/ or a later DBV version.

Why does this matter?

This change makes pipeline deletion behavior consistent between the HubSpot UI and the public API, and helps prevent accidental deletion of pipelines or stages that are still referenced by existing objects.

Integrations that currently rely on deleting in-use pipelines or stages may receive a 400 validation error after upgrading to /2026-09/. To preserve the previous behavior, explicitly set validateReferencesBeforeDelete=false, or validateDealStageUsagesBeforeDelete, or remain on an earlier version until you are ready to migrate.

Migration guidance

Before upgrading to /2026-09/, review any integration logic that deletes pipelines or pipeline stages. If your integration expects deletes to succeed even when a pipeline or stage is in use, update the request to pass false to the above mentioned query parameters. Otherwise, handle the new validation error and prompt users to remove references before retrying the delete.

Question or comments?

Join us in the community

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.

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.

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.

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.

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.

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.

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.

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.

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.