We noticed that hubspot rejects some records that we try to import using the Import API. In our case, our import file includes rows that are supposed to create and associate multiple objects. AFter some investigation we realized it’s because those records had badly formatted email address values, and hubspot failed to create both of the object records it was supposed to (even though none of them is a Contact object).
Has anyone encountered this issue and can recommend a good practice to work around it? For now our workaround is some development on the origin point of the call, but maybe there’s something better.
The API endpoints expect the data to be formatted in a specific way and when there is an issue with a record, it will not get created in HubSpot (even if it’s only a single property that is causing issues).
Therefore, it is important to send clean data. As you may have alluded to, the solution would be to build in safety mechanisms on the origin point that would either validate the data before sending or build logic that would attempt to re-send the data while excluding the “bad” properties that were identified by the API.
Hi @idanc , thanks for bringing this up. The Import API is surprisingly strict with email formats, and HubSpot treats anything that matches the email field pattern as an email candidate even when you’re not creating Contacts.
When that value fails validation, the entire row is rejected instead of letting the rest of the object creation proceed. HubSpot confirms this behavior in the property validation layer, where malformed values cause the whole row to fail rather than dropping just the problematic field (Review and troubleshoot record import errors ) It’s frustrating when you’re importing multi-object rows because one bad string can block multiple objects downstream.
The cleanest workaround I’ve seen is to sanitize or strip email-like values before the Import API ever sees them, especially in objects where email isn’t required.
Another option, if you need to preserve the raw value, is to map it to a text property that you’re confident won’t trigger HubSpot’s email validator. After import, you can re-format or relocate that value with a workflow or a follow-up API pass. It keeps the row intact while avoiding the validator entirely. If this becomes a bigger pattern across systems, Stacksync helps by normalizing fields before they reach HubSpot, so “bad” inputs in upstream systems don’t cascade into failed imports or broken associations.