On September 8, 2026, HubSpot ships its 2026-09 API version, and with it a genuine breaking change: admin-configured validation rules will be enforced on all CRM API write paths. Conditional required properties, required fields on the Create Record form, and user-level association permissions — guardrails that until now only applied to humans clicking around in the HubSpot UI — will start rejecting writes from your integrations, your middleware, and your AI agents. If your deal-creation sync has been quietly ignoring the rules your RevOps team configured, it is about to start returning 400 Bad Request.

Key Takeaways

• Starting with the 2026-09 API version (shipping September 8, 2026), HubSpot enforces conditional required properties, Create Record required fields/associations, and the “Edit Associations” permission on CRM API writes.
• The change is version-gated, not date-gated. Integrations pinned to 2026-03 or legacy v1–v4 endpoints keep working — but HubSpot’s date-based versions carry an 18-month support window, so this is a deferral, not an exemption.
• The highest-risk systems are the ones nobody owns: old Zapier and Make scenarios, iPaaS flows, and marketplace apps that will upgrade their API version on their schedule, not yours.
• Expect structured errors: MISSING_CONDITIONAL_REQUIRED_PROPERTY and MISSING_REQUIRED_PROPERTY, both returning 400.
• Two more HubSpot deadlines land in the same window: legacy private app creation is disabled September 28 (new accounts) and October 26 (existing accounts), and Pipelines API V1 reaches end of life December 4, 2026.
• This is the direction of travel across the category. Salesforce has always enforced validation rules on API writes; Zoho CRM makes it opt-in per request. HubSpot is closing the gap.

What Actually Changes on September 8

HubSpot’s changelog entry is short, but each of the three items has a different blast radius.

1. Conditional required properties now apply to API writes. If an admin has configured conditional property logic — say, close date is required when deal stage is Closed Won — a POST or PATCH that trips the condition without supplying the property now fails with MISSING_CONDITIONAL_REQUIRED_PROPERTY and a 400 response that names the offending property. Previously, that rule stopped at the browser.

2. Create Record settings apply to POST calls. Anything an admin marked required under Settings → Objects → [Object] → Create Record — properties or associations — is now enforced on record creation via the API, returning MISSING_REQUIRED_PROPERTY. This is the one that catches teams by surprise, because “required on the create form” felt like a UI convenience setting when it was configured, not an integration contract.

3. Association writes require the right permission. Apps using user-level OAuth need the “Edit Associations” permission (the CRM_ASSOCIATIONS_WRITE_ACCESS scope) to create, update, or delete associations. Portal-level tokens are unaffected. If you have an app authenticating as a specific user — a common pattern for agent and assistant integrations — that user’s permission set is now load-bearing.

HubSpot also notes a softer behavior change worth logging for: datetime normalization now returns a 200 with a warnings array describing any adjustment made to your input. That is not an error, but it is a signal that your payload wasn’t what you thought it was.

Why HubSpot Is Doing This Now

For most of CRM’s history, the API was a back door for machines and the UI was the front door for people, and only the front door had a lock on it. That was tolerable when the API carried nightly batch loads. It is not tolerable now, because the majority of writes hitting a mid-market HubSpot portal no longer come from a human.

HubSpot’s own remote MCP server gives authorized LLM clients read and write access to contacts, companies, deals, tickets, quotes, invoices, line items, and engagements. Layer on agent frameworks, revenue-intelligence tools, meeting notetakers, enrichment vendors, and the iPaaS flows already in place, and the practical question becomes: what is the point of a required-field policy that every non-human writer can ignore?

Enforcing admin configuration at the API boundary is the only version of data governance that survives contact with agentic tooling. You cannot instruct fifty integrations and three AI assistants to please respect your data model. You can only make the platform refuse writes that violate it.

Who Actually Gets Hit

The version gating matters enormously here, and it is where most of the confusion is. Nothing breaks on September 8 for an integration that keeps calling the endpoints it calls today. HubSpot’s date-based versioning ships breaking changes only in March and September, each version is immutable once released, and legacy semantic-version endpoints (v1 through v4) remain available at their existing URLs. Each GA dated version gets a minimum 18-month support window — roughly six months as Current, then twelve as Supported with critical fixes only.

So the exposure is not “my code calls the API.” The exposure is “something writing to my portal will move to 2026-09, and I won’t be the one who decides when.”

The failure mode is the dangerous part. A rejected write in a Zapier task or an iPaaS run rarely pages anyone. It becomes a record that silently never got created — a lead that never reached a rep, a deal that never made the forecast. You discover it in a pipeline review three weeks later.

How the Major Platforms Handle Admin Rules on API Writes

It is worth understanding where HubSpot is landing relative to the platforms you may also run, because the models genuinely differ and multi-platform teams get burned by assuming they behave alike.

Zoho’s model is the mirror image of HubSpot’s old one: workflows and approvals fire by default on API writes, but validation rules must be explicitly requested. Salesforce sits at the strict end — which is exactly why Salesforce shops have long-standing habits around designing validation rules that integration users can actually satisfy. HubSpot admins are about to need those same habits.

A Six-Step Audit to Run Before You Move

1. Inventory every writer. List everything that creates or updates HubSpot records: private apps, OAuth apps, marketplace connectors, iPaaS scenarios, custom code, MCP-connected agents. For each, record the owner, the auth method, and the API version it calls. Most teams cannot complete this step from memory — that is the finding.
2. Export your actual rule surface. Pull the conditional property logic on each object, the Create Record required fields and associations, and the association permissions on any user account backing a user-level OAuth app. Fetch live property definitions programmatically via GET /crm/{version}/properties/{objectType} rather than trusting a screenshot from last quarter.
3. Cross-reference rules against payloads. For each writer, compare the properties it actually sends against the rules that would now apply. Deals are the usual failure point: conditional requirements keyed to dealstage catch every integration that advances stages programmatically.
4. Test in a sandbox on 2026-09 before production. Point a test copy of each critical integration at the new version and replay a representative day of writes. You want the 400s in a sandbox log, not in your pipeline.
5. Fix the error handling, not just the payloads. Integrations should parse the returned error, identify the violated rule, and either correct and retry or raise a real alert. An integration that swallows a 400 is worse than one that crashes.
6. Decide, deliberately, whether each rule should apply to machines. Some required fields exist to make reps think. Applying them to a bulk enrichment job is pointless friction. This is a data-governance decision, not a developer decision — and it needs RevOps in the room.

The Rest of HubSpot’s Fall Developer Calendar

The validation change is not arriving alone, and treating these as one project saves a second round of regression testing.

• Legacy private app creation is being disabled. New accounts created on or after September 28, 2026 lose the option immediately; existing accounts lose it October 26, 2026. Existing legacy private apps keep working — only creation goes away. HubSpot points teams toward Service Keys (scoped access, built-in activity logging, key rotation with a seven-day grace period) available through Developer Platform Projects version 2026.09, or full Projects apps for webhook-dependent integrations.
• Pipelines API V1 reaches end of life December 4, 2026. Migrate to 2026-03 or later before then.
• The versioning cadence itself is the plan. Two releases a year, in March and September, with 18 months of support each. That replaces the old 90-day deprecation-notice model and means you can now schedule API maintenance as a predictable twice-yearly exercise instead of a fire drill.

Common Mistakes We Expect to See

• Loosening the rules to make the errors go away. The fastest way to “fix” a 400 is to un-require the field. That trades a visible integration failure for invisible data decay, which is the more expensive problem.
• Assuming marketplace apps are someone else’s risk. They write to your portal under your name. When the vendor upgrades, the failures are yours to explain.
• Forgetting that imports and workflows are writers too. Any path that creates records deserves a line in the inventory.
• Pinning to an old version and calling it done. An 18-month window feels generous until it isn’t. Put the migration on the roadmap now, at the pace you choose.
• Testing only the happy path. The valuable test is the record that should be rejected. Confirm the rejection surfaces somewhere a human will see.

CRM Experts Online’s Perspective

We spend a lot of our week inside portals where the data model on paper and the data model in practice diverged years ago. The pattern is nearly always the same: an admin configured sensible guardrails in the UI, and then five integrations were built that never saw them. The reporting layer inherits the mess, someone concludes the CRM “doesn’t work,” and a replatforming conversation starts that should have been a governance conversation.

So we read this change as HubSpot doing its customers a favor, delivered inconveniently. The 400s you get in September are not new problems. They are existing problems becoming visible, in a controlled way, on a version you opt into. That is close to the best-case scenario for surfacing integration debt.

The mistake we would most want a client to avoid is the reflex fix — stripping requirements out of the Create Record settings so the sync goes green again. Before you touch a single rule, ask why it was configured. If it protects a field that drives routing, forecasting, or renewal reporting, the integration should be sending it. If it exists because someone once wanted reps to fill in a source field, and it is now blocking a legitimate machine write, then remove it consciously and document the decision.

Practically, we would sequence the work as: inventory and version-map every writer this month, fix payloads and error handling in a sandbox on 2026-09, migrate the highest-value integrations first, and bundle the private-app and Pipelines V1 migrations into the same release so you regression-test once. For most mid-market portals that is a two-to-four week engagement, not a quarter.

FAQ

Will my integrations break on September 8 if I do nothing? Not automatically. Enforcement applies to the 2026-09 API version. Code pinned to 2026-03 or legacy v1–v4 endpoints keeps its current behavior — but any third-party app that upgrades will bring the new behavior with it.

How do I find out which version a third-party app uses? Ask the vendor directly and get a date for their 2026-09 migration. For anything critical, put that date in your calendar and test around it. Your API call logs will also show which endpoints are being hit.

Which errors should I expect? MISSING_CONDITIONAL_REQUIRED_PROPERTY and MISSING_REQUIRED_PROPERTY, both as 400 responses that identify the property involved. Association failures return a message about the missing “Edit Associations” permission.

Does this affect private app tokens? The association-permission requirement applies to apps using user-level OAuth. Portal-level tokens are not affected by that specific piece. The property-validation rules apply to writes regardless of auth type once you are on 2026-09.

Do I need to migrate off legacy private apps right now? Existing legacy private apps continue to work. Only creation is being disabled — September 28 for new accounts, October 26 for existing ones. Plan the migration to Service Keys or Projects apps, but it is not an emergency.

How does this affect AI agents connected to our CRM? Positively, in our view. An agent writing through the API is now subject to the same required-field and association rules as a rep. That is the enforcement point that makes agent access governable rather than hopeful.

We also run Salesforce and Zoho. Do we need to do this there too? Salesforce already enforces validation rules on every API and Bulk API write, so the equivalent work is auditing whether your rules are satisfiable by integration users. Zoho CRM is the opposite — validation rules run only when the request explicitly includes apply_feature_execution with criteria_validation_rule, so it is worth checking whether your Zoho integrations are bypassing rules you assumed were enforced.

Should we bulk-load historical data before the change? No. Rushing imports to beat a validation deadline is how bad data gets permanently embedded. If a load can’t satisfy your own rules, fix the load or the rule.

Conclusion

September 8 is a small change with a large diagnostic value. For the first time, HubSpot will tell you exactly which of your integrations have been writing around your data governance — and it will tell you in a version you control the timing of. Teams that treat it as a migration chore will loosen a few rules and move on. Teams that treat it as an audit will come out with an accurate inventory of every system writing to their CRM, working error handling, and a data model that machines and humans both respect.

If you don’t have a confident answer to “what writes to our CRM, with what credentials, on what API version,” that’s the gap worth closing this month. Schedule a consultation with CRM Experts Online and we’ll run the integration inventory, test your critical writers against 2026-09 in a sandbox, and get the migration done before a failed sync finds it for you.

Further Reading

• HubSpot: Breaking Change — CRM API Write Validation Enforcement Starting with the 2026-09 API Version
• HubSpot Docs: Developer Platform and API Versioning
• A Developer’s Guide to HubSpot’s Date-Based API Versioning
• HubSpot: Legacy Private App Creation Being Disabled
• HubSpot MCP Server documentation
• HubSpot Knowledge Base: Set Up Conditional Logic for Enumeration Properties
• HubSpot Knowledge Base: Set Up Fields Seen When Manually Creating Records
• Zoho CRM V8 API: Insert Records (apply_feature_execution and trigger)
• Salesforce Metadata API Developer Guide: ValidationRule

John M Perez

CRM & ERP Enterprise Technology Expert and Entrepreneurial Executive with 20+ years of leading CRM, ERP, Customer Experience, and Block-chain initiatives and projects across internal and customer facing technologies.  Proven success in closing large deals in Pre Sales customer facing engagements and deploying enterprise wide CRM & Customer Experience solutions internationally and domestically.