Your HubSpot validation rules are about to start doing a great deal more work. From 8 September 2026, when the /2026-09/ version of HubSpot’s CRM API ships, the rules your administrators configured in the interface will be enforced on API writes as well. Conditional required properties, required fields on record creation, and association permissions all move from being an interface convention to being a platform guarantee. For teams who have already invested in getting their data model right, this is a quiet upgrade with a large payoff.
It is worth stating plainly what that means in practice. Until now, a rule that stopped a sales representative from marking a deal closed and won without a close date applied only when a human was clicking through the interface. The same record could be created or updated through an integration, a migration script or a partner application with none of those checks running. From September, on the new API version, the rule holds on both sides. The governance you designed becomes the governance you actually get.
HubSpot has labelled this a breaking change, and technically it is one. It is also one of the more useful breaking changes a CRM vendor has shipped this year, because the thing it breaks is the gap between what your organisation decided and what your systems enforced. Teams who spend a fortnight preparing will come out the other side with cleaner integrations, better error handling and a data model they can trust in front of an executive audience.
What exactly ships on 8 September 2026?
HubSpot’s /2026-09/ API version, released on 8 September 2026, enforces three categories of administrator-configured validation on all CRM API write paths. Conditional required properties, where one property becomes mandatory because another holds a particular value, return a 400 error with the code MISSING_CONDITIONAL_REQUIRED_PROPERTY when the required value is absent. Required properties and associations set in Create Record settings are enforced on POST calls, returning MISSING_REQUIRED_PROPERTY. And user-level OAuth applications need the Edit Associations permission, carried by the CRM_ASSOCIATIONS_WRITE_ACCESS scope, before they can create, update or delete associations. Portal-level app tokens are not affected by that third rule.
The detail that makes this comfortable to plan around is that the change is tied to the API version rather than to the calendar. Existing integrations running on earlier versions carry on behaving exactly as they do today. You adopt the new enforcement when you move an integration to /2026-09/, which means the timing is yours to choose and you can sequence the work integration by integration rather than facing a single cutover. A beta of the version is already available for testing, so there is a straightforward path to verification before anything reaches production.
The response payloads have been made more helpful too. Validation failures come back with specific error codes and messages naming the property at fault, which is a considerable improvement on debugging a silent bad write six weeks later. HubSpot has also started populating a warnings array on responses for things such as datetime normalisation, giving integration owners a signal on writes that succeed but have been adjusted.
What is CRM data quality, and why does enforcement raise it?
CRM data quality is the degree to which the records in your customer relationship management system are accurate, complete, consistent and current enough to be trusted for decisions and automation. In practical terms it is measured record by record: whether a deal carries the fields your forecast depends on, whether a company exists once rather than four times, whether the close date on a won opportunity reflects what actually happened. Quality is not a property of the data alone. It is a property of every path by which data arrives, which is why validation at the API boundary matters as much as validation in the interface.
That distinction is the whole story here. In most B2B portals, the majority of record writes never involve a person typing into a form. They arrive from a marketing automation sync, an ERP integration, a web form handler, an enrichment provider or a data migration. If your rules only ever ran against the smaller, human-generated share of writes, then your rules were describing an aspiration rather than a standard. Closing that gap does more for measurable data quality than any amount of retrospective cleaning, because it changes the input rather than the output.
There is a pleasing second-order effect as well. Once the platform enforces the standard, the standard becomes visible. Integration owners find out immediately when a payload does not carry what the business requires, rather than discovering it during a quarterly review when nobody can remember which system wrote the record. Fast, specific feedback is what turns data quality from a periodic clean-up project into an ordinary operational habit.
Why does this matter more now that AI agents write to the CRM?
CRM data quality is important because every downstream system inherits it. Forecasting, lead routing, reporting, territory planning and increasingly the AI agents sitting on top of the CRM all read from the same records, and none of them can compensate for a field that was never populated. An agent asked to summarise an account or propose a next step works from what the record contains. Where the record is complete and consistent, the output is genuinely useful. Where it is not, the agent produces something plausible and wrong, which is harder to catch than an obvious blank.
This is the part that makes the September change well timed rather than merely tidy. HubSpot’s own agent capabilities, along with the growing set of custom agents teams are building inside the platform, write to the CRM through the same API surface as everything else. Applying the organisation’s validation rules to those writes means an autonomous process cannot quietly create the kind of incomplete record a person would have been stopped from creating. That is a meaningful piece of AI governance delivered as a platform default, and it arrives without anyone having to write a policy document for it.
Which portals need to act, and how should they prepare?
The blast radius here is narrower than the phrase breaking change suggests, and it lands exactly where the preparation pays off. HubSpot has been explicit that portals with no conditional required properties configured, no required fields or associations in Create Record settings, and no association permission restrictions in play will see no behavioural difference at all. Nothing to do, nothing to test. The change only touches portals that have already taken the trouble to define rules, which is to say the more mature ones.
If you are in that second group, the practical question is simply which of your integrations write to objects covered by a rule. A portal with a conditional requirement on deal close date needs to look at anything that creates or updates deals. A portal that requires a primary company association on new contacts needs to look at its form handlers and enrichment jobs. This is a short list in most organisations, and it is a list worth having written down whether or not HubSpot had announced anything.
Start with an inventory of every application, script and connector that writes to your portal, along with the object it touches and the token it authenticates with. Then pull your current property definitions with a GET call so you have an authoritative list of what is required and under which conditions, rather than working from institutional memory. Update the write payloads that need additional properties, and make sure each integration parses a 400 response and surfaces the specific validation message instead of retrying blindly or logging a generic failure.
For user-level OAuth applications, check that the Edit Associations permission is in place for the users those applications act on behalf of, and confirm the CRM_ASSOCIATIONS_WRITE_ACCESS scope is requested where associations are being written. Then run the whole set against the beta version well before 8 September so the first encounter with the new behaviour happens in a test portal rather than in production on a Monday morning.
Every item on that list has independent value. An accurate inventory of what writes to your CRM is the single most useful artefact in any migration, audit or platform consolidation, and most organisations do not have one. Integrations that read property definitions rather than hard-coding them survive schema changes gracefully. Error handling that parses validation messages turns silent data corruption into an actionable alert. A fortnight spent here buys improvements that outlast this particular release by years.
What is CRM technical debt, and how does this reduce it?
CRM technical debt is the accumulated cost of shortcuts taken inside a CRM platform: undocumented custom fields, integrations that bypass business rules, automation that nobody owns, and the same logic implemented in three places because no single place was authoritative. It compounds quietly, since each shortcut works perfectly on the day it ships and only causes trouble later, usually during a migration, an audit or an AI project. The most expensive variety is logic that exists on one write path but not another, because it produces records that look valid and are not.
What HubSpot has done is retire one of the most common instances of that pattern across every portal at once. Rules that previously had to be duplicated inside each integration, or accepted as unenforceable, now live in one place and apply everywhere. That is less custom validation code to maintain, fewer divergent copies of the same business rule, and a smaller gap between the documented data model and the real one. Debt reduction delivered by the vendor is the cheapest kind there is.
How does enforcement improve CRM adoption?
CRM adoption improves when people trust what the system tells them. The most damaging adoption failures are rarely about training or interface design: they happen when a sales manager pulls a pipeline report, spots a deal with a missing or obviously wrong field, and concludes that the numbers cannot be relied upon. From that point the team keeps a spreadsheet alongside the CRM, and the platform quietly becomes a system of record for nothing. Consistent enforcement across every write path removes a large share of the records that trigger that reaction.
There is also a fairness argument that lands well with revenue teams. Asking a representative to complete six fields before closing a deal is a much easier conversation when the same requirement demonstrably applies to the integration that created two hundred records overnight. Rules that apply to everyone are followed. Rules that only apply to the people using the interface are experienced as an administrative tax, and get worked around accordingly.
The Sirocco perspective
We work across Salesforce, HubSpot and Microsoft Dynamics 365, and we are seeing the same movement on all three platforms: governance is shifting from something you configure in the interface and hope holds, to something the platform enforces at every boundary. HubSpot’s September API version is a clear and well-executed example, and we like seeing it ship as a default rather than as a premium add-on. It raises the baseline for everyone who builds on the platform.
Our advice to clients this month is straightforward and mostly not about HubSpot. Use the deadline as the reason to finally document what writes into your CRM, which rules you want enforced, and who owns each integration. Teams that do this arrive at the September release with nothing to fix, and they arrive at their next migration or AI project with the groundwork already done. The organisations that will get the most from agentic CRM over the next two years are the ones treating data governance as an enabler rather than a chore, and this is an unusually cheap opportunity to move in that direction.
If you would like a second pair of eyes on your integration inventory, your validation rules or your wider HubSpot data model, we would be glad to talk it through. You can schedule a consultation with our team whenever it suits you.
Get in Touch
If you are mapping which integrations write into your HubSpot portal before the 8 September API version lands, we are glad to work through that inventory with you.
