hs_timestamp field is unset while making PATCH request on Email type of entity

[ASuthar]

I'm currently using and Integration and Migration tool known as OpsHub Integration Manager. Where one issue while developing the connector HubSpot with the OpsHub Integration Manager I'm facing is, when I do PATCH call to update Email  entity type, in my current implementation, whenever I make an PATCH request I provide the mandatory field hs_email_direction with value.

But still sometimes when I try to sync the Email entity, then it gives me the below error 
REST query. URL: https://api.hubapi.com/crm/v3/objects/emails/89699720276,HTTP method: PATCH, status code: 400, exception: {"status":"error","message":"Error updating EMAIL. Some required properties were cleared.","correlationId":"e9e4feae-43b7-4fd4-823c-b27153fc9508","context":{"properties":["hs_email_direction"]},"category":"VALIDATION_ERROR"}


So is there any issue in the current API when we concurrently makes mulitple requests or not.

[Christensen · Accepted solution]

Hey @ASuthar, please verify that the hs_email_direction property is being passed with a valid, non-empty value in your payload. This error typically occurs when the field is sent as an empty string or null, which causes HubSpot to clear the property from the payload and since it’s a required property, the API rejects the update.

Refer to the official HubSpot documentation for the list of acceptable values for hs_email_direction: https://developers.hubspot.com/docs/api-reference/crm-emails-v3/guide

Moderator note: While this solution may not address the original poster’s specific situation, it could be helpful for other community members facing similar challenges.

[Christensen · Accepted solution]

If the payload is being passed correctly, could you try sending the exact same payload manually via Postman to confirm whether it succeeds?

If it works in Postman but fails through your code, the issue is likely related to how your library or serialization process is handling the data.

Testing it directly in Postman will help isolate whether the problem is with the HubSpot API itself or with how your code constructs and sends the PATCH request.

Moderator note: While this solution may not address the original poster’s specific situation, it could be helpful for other community members facing similar challenges.

[ASuthar]

@Christensen , thanks for the information, but still didn't get any concrete documentation for the unusual behaviour in this API.

[BérangèreL]

Hi @ASuthar, I hope that you are well! Thanks so much @Christensen for your help!

To access email and meeting engagement data via API, you need the sales-email-read scope (for email content) along with standard CRM object scopes.

The scopes crm.objects.meetings.read and crm.objects.emails.read should be available when setting up OAuth for your app.
 

For n8n integration:

- Use the Meetings API to retrieve meeting data
- Use the Email Engagements API to retrieve email data
- Ensure your OAuth app includes both scopes in the auth settings

If these scopes aren't appearing in your app's scope list, you may need to enable advanced scope settings in your HubSpot app configuration (available since April 2024).

Check your app's auth settings to add these as required or conditionally required scopes.

Let us know how it goes!
Bérangère

This post was created with the assistance of AI tools.

[ASuthar]

@Christensen , Thanks for your responses, but how you are sure about this as no such behaviour is occuring in the API.

[Christensen]

If this were a "concurrency"-related issue, you’d typically see a 429 status code with a RATE_LIMITS category. However, your error shows a 400 status with VALIDATION_ERROR, which means the problem occurred during data validation, not due to concurrent requests.

That indicates the request payload is failing schema validation (in this case, the hs_email_direction property being empty or invalid), rather than HubSpot rejecting it for "concurrency" or rate limiting.

[Christensen · Accepted solution]

Hey @ASuthar, please verify that the hs_email_direction property is being passed with a valid, non-empty value in your payload. This error typically occurs when the field is sent as an empty string or null, which causes HubSpot to clear the property from the payload and since it’s a required property, the API rejects the update.

Refer to the official HubSpot documentation for the list of acceptable values for hs_email_direction: https://developers.hubspot.com/docs/api-reference/crm-emails-v3/guide

Moderator note: While this solution may not address the original poster’s specific situation, it could be helpful for other community members facing similar challenges.

[ASuthar]

yes have validated that, it is passing correctly, still getting this type of error.

[Christensen · Accepted solution]

If the payload is being passed correctly, could you try sending the exact same payload manually via Postman to confirm whether it succeeds?

If it works in Postman but fails through your code, the issue is likely related to how your library or serialization process is handling the data.

Testing it directly in Postman will help isolate whether the problem is with the HubSpot API itself or with how your code constructs and sends the PATCH request.

Moderator note: While this solution may not address the original poster’s specific situation, it could be helpful for other community members facing similar challenges.

[ASuthar]

normally using Postman it is working fine, but I think the main issue is in concurrent API requests being made for updating the Email entity.

[Christensen]

If it’s working consistently in Postman, then concurrency by itself wouldn’t cause the hs_email_direction field to be cleared. The HubSpot API doesn’t clear required properties automatically during simultaneous updates.

This error still indicates that at least one of your requests is sending an empty or invalid value for hs_email_direction. I’d recommend logging each concurrent request’s payload to confirm that the property is always populated before the PATCH call is made. Even small timing differences or serialization issues in your code can result in an empty field being passed intermittently.

[ASuthar]

I absolutely agree with your point,  but what if there could be some delay in updating the data from the API and being reflected on the UI.

Let's say in first event the Email Direction field is being set with some value using the API, now immediate another API call on the same entity is made.

And in this event, first it fetches the field value for the for the current Email entity, now during this fetch it might get this Email direction field empty (which ideally should be updated by the initial API call.)

Now when this second PATCH request is made then at that time it will have this stale state of the Email Direction field, which results in such issue.

[Christensen]

The delay in the UI vs API is a known behaviour however the stale state you are talking about should be handled in your code not by the HubSpot API endpoint because when making a request in an endpoint, it expects that you are following the schema hence why it was returning a validation error.

[ASuthar]

@Christensen , can you please let me know where this delay's known behaviour is mentioned

[Christensen · Accepted solution]

@ASuthar no official mention of this behavior specifically for the UI, but it’s a long-observed pattern noted by developers working with custom integrations. The only documented reference to this delay appears in the Search API limitations section of HubSpot’s official documentation: https://developers.hubspot.com/docs/api-reference/search/guide#limitations

Limitations
"It may take a few moments for newly created or updated CRM objects to appear in search results."