Has anybody else begun testing with the /2026-09/ API version? I realized that HubSpot has begun to enforce admin validation rules in all CRM API write operations starting from September 8. Wondering what other marketing agencies have been doing about it, particularly for applications which create or modify contacts or deals. Do you plan to test in sandbox mode or are you upgrading API operations already?
Hi @SamuelOliver, I hope that you are well!
Thanks for starting this great topic on the HubSpot Community!
On my side, I can confirm what’s changing (as of /2026-09/, live Sep 8, 2026): HubSpot now enforces admin-configured validation rules on all CRM API write paths, not just the UI. Three behaviors are enforced:
- Conditional required properties (e.g.,
close_daterequired whendealstage=closedwon) → returns400withMISSING_CONDITIONAL_REQUIRED_PROPERTY. - Record creator settings — required properties/associations set in Settings → Objects → [Object] → Create Record are now enforced on
POST. - Edit Associations permission — user-level OAuth installs without the Edit Associations permission (
CRM_ASSOCIATIONS_WRITE_ACCESS) get errors on association writes. Portal-level app tokens aren’t affected.
This only triggers if a portal admin has actually configured these rules, no config means no behavior change.
Here is the recommended prep: fetch current property definitions via GET /crm/{version}/properties/{objectType} before writes, ensure conditional/required properties are included, and confirm your installing user has Edit Associations if you write associations. Testing in a sandbox against /2026-09/ before switching production traffic is a reasonable way to catch these validation errors early.
Here is the documentation about this: Date-based API versioning
I’d love to hear from our Top Experts: Hi @Anton, @SteveHTM and @Alex_Boissonneault do you have any insights to share with @SamuelOliver, please?
Thanks so much and wishing you a lovely day!
Bérangère
This post was created with the assistance of AI tools
Dear Bérangère,
Thank you very much for the detailed explanation. This is very useful information. Conditional Required Properties and Record Creator are the types of things that could really mess up an integration.
The suggestion about testing in a sandbox is excellent. I have been doing the same with my own configurations.
I appreciate the mention of the experts too. Can’t wait to hear from them.
Many thanks!
Hey @Berangere Thanks for looping me in. And good timing, we went through this last week.
Honest take from the agency side, the Create Record settings are what got us, not the closed-won rule. One client portal had “Lead Source” required on the contact create form since 2022. Nobody remembered. Their form-to-CRM integration started throwing 400s the moment we pointed it at /2026-09/ in sandbox. Would have been ugly in prod.
So my advice is boringly simple, before you touch code, open Settings > Objects > Contacts and Deals > Create Record on every portal you manage and screenshot what’s required. Most of the “fix” is just knowing that list exists.
Then sandbox first, always. Push a handful of real-looking creates through and a couple of stage moves to closed won. Errors show up in minutes.
And check who installed your user-level apps. If it’s the ex-marketing manager who left in March, the association writes will fail regardless of how clean your payloads are.
We’re moving low-volume integrations first, watching logs for a week, then the deal sync. No big-bang switchover.
Hope it helps!
We usually handle HubSpot CRM API write validation in two layers.
First, we validate the data before making the API request — checking required fields, data types, formats, property values, and any important business rules. This helps prevent avoidable API failures.
Second, we still treat HubSpot as the final source of truth because validation rules and CRM configurations can change in the HubSpot portal. We properly parse HubSpot’s API response and identify which property or validation rule caused the write to fail.
For a validation error such as a 400 response, we don’t repeatedly retry the same request. Instead, we log the error and correlation ID, correct the data, and then submit the request again. For temporary errors such as rate limits (429) or server errors (5xx), we use controlled retries with backoff.
This approach gives us better data quality, easier troubleshooting, and a more reliable CRM integration while avoiding duplicate or invalid records.
Hi Sanjay
Great share; very nice implementation. Having the two-tiered validation is a good idea, especially the pre-request validation before the API call. That by itself should weed out much of the noise.
Just curious though; how do you manage your pre-request validation among your many custom objects? Do you have a cache of your property definitions, or do you get fresh each time?
Additionally, have you seen the /2026-09 validation rules catch anything your pre-request validation missed?
Hi Samuel,
For custom objects, we definitely avoid fetching the property definitions on every write, as that would add unnecessary API calls and latency.
Instead, we cache the relevant object and property metadata using a controlled Time-to-Live (TTL). This cache is refreshed immediately if a schema change is detected, or when HubSpot returns a validation error indicating that our cached definition might be outdated. While the cache handles our pre-request validation, HubSpot always remains the final source of truth.
This approach is especially important with the /2026-09 API version, where HubSpot actively enforces admin-configured rules like conditional required fields on API writes. If an admin modifies a rule in the portal after our metadata is cached, HubSpot will return a 400 Bad Request validation error. When that happens, our system is designed to:
- Parse the error response
- Evict and refresh the outdated metadata cache
- Correct the payload (if programmatically possible) or flag it
- Retry the request rather than repeatedly sending invalid data
We haven’t seen a specific production case yet where the /2026-09 validation rules caught something our pre-validation completely missed. However, we specifically built the integration to handle this scenario gracefully, since portal-level rules can change independently of our code.
Hi Samuel,
For custom objects, we definitely avoid fetching the property definitions on every write, as that would add unnecessary API calls and latency.
Instead, we cache the relevant object and property metadata using a controlled Time-to-Live (TTL). This cache is refreshed immediately if a schema change is detected, or when HubSpot returns a validation error indicating that our cached definition might be outdated. While the cache handles our pre-request validation, HubSpot always remains the final source of truth.
This approach is especially important with the /2026-09 API version, where HubSpot actively enforces admin-configured rules like conditional required fields on API writes. If an admin modifies a rule in the portal after our metadata is cached, HubSpot will return a 400 Bad Request validation error. When that happens, our system is designed to:
- Parse the error response
- Evict and refresh the outdated metadata cache
- Correct the payload (if programmatically possible) or flag it
- Retry the request rather than repeatedly sending invalid data
We haven’t seen a production case yet where the /2026-09 validation rules caught something our pre-validation completely missed. However, we specifically built the integration to handle this scenario gracefully, since portal-level rules can change independently of our code.
Hello Sanjay,
Thank you very much for the details. It looks like a good solution to use TTL based cache with immediate refresh upon validation errors.
Question: When you evict and refresh the metadata cache in case of a 400 error, how do you deal with requests which might be trying to access the stale metadata cache simultaneously? Do you block them until the refresh completes or allow to fail and then try again with the correct metadata?
Also interested in how you are able to determine schema changes which are not related to any validation errors – do you poll for them or wait for the errors from HubSpot to perform the refresh?
Thank you for the information about the /2026-09 changes.