Your required fields were never required

A HubSpot admin can now write a data rule once, in Settings, and have it hold against every robot pointed at the CRM: the AI agent, the overnight sync, the Zap somebody built in 2023 and left running under a login nobody has audited since. Until this week that rule was decoration everywhere except a browser tab. Keeping it true on the API side meant writing the same check a second time inside every integration that touches the account, and then paying somebody to clean up the records that got in anyway, every quarter, forever. HubSpot said on Tuesday that starting with the September version of its API, the rules an admin configures in the interface apply to API writes too.

What actually changed

The changelog entry is short, and it is labelled a breaking change, which HubSpot says out loud rather than burying. From the /2026-09/ API version, shipping September 8, three admin-configured rules start applying to every CRM write that arrives over the API.

Conditional required properties are the big one. If an admin has set up a rule making one property required when another has a particular value, the classic being a close date that becomes mandatory the moment a deal is marked closed won, the API will now reject a write that leaves it blank. HubSpot's own description of the old behavior is the line worth reading twice: "Previously, these rules were UI-only and the API ignored them."

Second, required fields on the Create Record form. If an admin marked a property or an association as required at creation time, that requirement now applies to records created over the API, not just to a person filling in a form on screen. Third, association permissions: if an app authenticates as a specific user rather than as the portal, and that user lacks the Edit Associations permission, calls that create, update or delete associations will fail. Portal-level tokens are unaffected.

There is a fourth item in the same post that is a gift rather than a bill. Date handling gets more forgiving. Inputs that used to be rejected outright, off-midnight timestamps, ISO strings, plain epoch seconds, now get normalized, and the response carries a warnings array describing what was changed. The genuine failures that remain come back with the raw input, the parsed interpretation, and the constraint that was violated, which is a real improvement over a bare INVALID_DATE.

None of it does anything on a portal where no such rules exist. If your Settings are empty, your writes behave exactly as they did yesterday.

The hole this closes

Here is the shape of the problem, and it is worth naming precisely, because it explains why so many CRMs are dirty in the same specific way.

Every data rule a HubSpot admin has ever written applied to exactly one kind of writer: a human being, in a browser, on the record page. That was a defensible design in 2015, when a human in a browser was how the overwhelming majority of records got created and changed. It is not defensible now. Count the things writing to a mid-sized portal today. The web forms. The marketing sync. The enrichment vendor. The ticketing integration. Two or three internal scripts whose author has left. An accounting connector. And, increasingly, some flavor of AI agent that a non-engineer wired up on a Friday afternoon.

HubSpot has been actively encouraging that last category. Its own Agent CLI went to public beta in June, described in the announcement as purpose-built for AI agents to create and update objects and manage pipelines, properties, associations and workflows, and explicitly well suited to "scheduled automations, bulk operations, and background tasks that need to run without a human in the loop."

Read those two facts next to each other. The vendor spent the spring shipping tools that let more non-humans write to the CRM faster, into a system where the data rules only ever applied to humans. The gap did not open on Tuesday. Tuesday is when they started closing it.

This is also why the dirty data in a CRM is never randomly dirty. It clusters. The deals with a missing close date are the ones the integration created. The contacts with no lifecycle stage came in through the path that skipped the workflow. Anyone who has run a cleanup pass knows the pattern: you are almost never cleaning up after your colleagues. You are cleaning up after a machine that was never told the rules, because there was no mechanism to tell it.

What it is actually worth

Two line items, and the second is bigger than it looks.

The first is the duplicated logic. Today, if a rule genuinely matters, the only way to make it stick is to implement it a second time inside every integration that writes. That is real work. It has to be written, tested, and then maintained in lockstep with a Settings page that somebody else can change without telling you. Most teams never do it. They write the rule once, in the interface, and quietly accept that it half applies. Which means it is not a rule. It is a preference that humans respect and software ignores.

The second is the recurring cleanup. Ops teams either pay for a hygiene and dedupe tool, or they hand somebody a quarterly project, or both. Either way it is a standing cost that exists because bad records keep arriving. Moving the check to the door does not delete that work, but it changes its character, from a permanent tax into a one-time backlog. Those are very different things to carry on a small team.

There is a forecasting angle too, and for an owner-operator it is the one that bites hardest. A pipeline report is only as good as the properties it groups by. Deals with no close date do not show up in a monthly forecast at all. They sit in a bucket nobody opens. The business does not experience that as a data problem. It experiences it as a forecast that is quietly wrong in the same direction every month for reasons nobody can locate.

The honest take

Now the parts that are not in the headline.

September 8 is not a deadline. This is the single most important thing to understand, and it is what most coverage of this will get wrong. HubSpot moved to date-based API versioning this spring. Versions ship twice a year, each one is immutable once released, and each carries a minimum eighteen-month support window. The new enforcement lives in /2026-09/. Your integration does not move to /2026-09/ until you move it. If you own your scripts, nothing breaks on September 8, and nothing gets fixed either. The rules begin applying when you opt in, which for most small teams will be well after September and for some will be never.

It is, however, a deadline for the software you did not write. The marketplace app you installed upgrades on its developer's schedule, not yours. You will not be consulted and you may not be told. HubSpot's preparation guidance is aimed at app developers, and its first instruction is revealing: "Suggest users of your integration to review the account your app writes to." The notification job is being handed to a third party with no particular incentive to do it well. So the realistic experience for an admin is not a planned migration. It is an app that worked on Tuesday and started throwing errors on Thursday because somebody else shipped.

A rejected write is worse than a bad one, in one specific way. Bad data announces itself eventually. Somebody runs a report, a number looks wrong, you go find the records. A 400 error on a write nobody is watching produces no record at all, and a record that was never created looks exactly like a thing that never happened. If your integrations log failures somewhere a person actually reads, you are fine. If they are a chain of no-code steps whose error branch has never been tested, you will lose writes silently. That is a genuinely worse failure mode than the one being fixed, and it lands hardest on the teams least equipped to spot it.

Related, and this is HubSpot telling on the tooling: the guidance includes the instruction "Do not retry the same request unchanged." That sentence exists because they know exactly what a lot of low-code platforms do when they get a 400, which is try again, and then try again. A validation error will never pass on retry. It will just eat your task quota until something else falls over.

The associations rule is a people problem in a code costume. It keys off the permissions of the installing user. Not the app, the person who connected it. So the failure arrives when that person leaves, changes roles, or has their permissions trimmed during a tidy-up that had nothing to do with integrations. An admin doing responsible access housekeeping in November can break a sync that has run cleanly for two years, and nothing in either interface will connect those two events for them.

Who this is genuinely wrong for. There is a large population of ops people using the API precisely because it ignores the rules. The bulk import that has to skip a required field. The migration that loads records in an order the validation would never permit. The correction script that touches a thousand deals without filling in a property that applies to none of them. That escape hatch is being welded shut, and while closing it is the right call, "the right call" and "painless" are different phrases. If a process of yours depends on the API being the lawless door, find another way in before you upgrade a version, not after. The same release does this to pipelines as well: from /2026-09/, deleting a pipeline or stage that is still in use is blocked by default, where it previously went through.

And the quiet prerequisite. None of this pays out unless the rules exist. Enforcement against an empty Settings page enforces nothing. Most portals have a handful of required fields configured years ago by somebody who has since left, and no conditional rules at all. The work this change makes worthwhile is the work nobody wants to do: sitting down and deciding what actually has to be true about a record before it is allowed to exist. HubSpot just made that afternoon worth spending. It did not spend it for you.

Then month three. The drift problem is real and unaddressed. An admin adds a conditional required property in November. Every integration written before November now fails, and nobody tells the person who owns the script, because the person who owns the script is usually not in the room where properties get changed. HubSpot's answer is to poll the properties endpoint and detect the change yourself, which is a reasonable engineering answer and a completely unreasonable one for the non-coding builder this whole capability is aimed at. The admin who can now stand up an agent in an afternoon is not going to write a settings-drift monitor.

The lock was on the wrong door

What is interesting here is not the validation. It is what the change admits about the last few years. The browser was the only door with a lock on it, and for a long time that was fine, because everyone came in through the browser. Then we spent three years handing keys to software, and the software walked past the lock every single time, and we called the mess that produced a data quality problem, as though the data had done it to itself.