Hi there,
We have a custom workflow that sends a webhook to a custom endpoint on Feedback Submission. It has worked great until recently, with no changes made to this, I’m getting a 422 response error. We’re passing all the properties from the feedback submission, with that we make a subsequent call for get properties on the contact and to send a transactional email.
Looking at the request sent, the version for the Feedback Survey is null. The 422 is erroring out and saying that the version needs to be a valid integer. This is not something we’re requiring nor did we specify the data type, I’m wondering if any one has experienced this, or if there is any guidance in this space?
Thank you so much for your time and consideration!
Hey @RHarkins - thanks for posting in the Community!
I’d like to tag in some experts to see if they have any insight for us here! @ChristinaKay, @beeginman, and @Teun - any thoughts on how @RHarkins can resolve this 422 error?
Shane, Community Manager
Possible Issues:
- HubSpot API or Workflow Changes: Even though you haven’t made changes to your workflow, HubSpot might have updated how it handles or validates certain fields. This could include stricter validation rules for properties like version. It’s worth checking the HubSpot Developer Changelog to see if there’s been any recent update affecting Feedback Submissions or webhook payloads.
- Validation Rules on the Receiving Endpoint: If the custom endpoint you’re sending the webhook to has updated its validation logic, it might now require version to be a valid integer. This could be a new requirement introduced by whoever manages that endpoint.
- Null Value Handling: If the version field is null in the payload, it might be because the Feedback Survey doesn’t have a version value set in HubSpot. This could happen if the survey was created or updated in a way that didn’t assign a version, or if the field wasn’t required previously but now is.
Steps to Troubleshoot and Resolve:
- Inspect the Webhook Payload: Use a tool like Postman or your server logs to capture the exact payload being sent to the endpoint. Look for the version field and confirm if it’s null.
- Set a Default Value for version: If the version field is null, you can use a HubSpot workflow action to set a default value before the webhook is triggered. For example, you could use a custom property or a calculated property to ensure version always has a valid integer value.
- Update the Receiving Endpoint: If you have control over the custom endpoint, consider updating its validation logic to handle null values gracefully. For instance, you could default null version values to 1 or another appropriate integer.
- Check HubSpot Validation Rules: If the issue is on the HubSpot side, review the validation rules for the Feedback Survey properties. You might need to update the survey or its associated properties to ensure version is always populated.
- Retry Logic: If the webhook fails due to this error, HubSpot won’t retry the request (since it’s a 422). You’ll need to manually reprocess the failed submissions or implement a retry mechanism in your workflow.
- Reach Out to HubSpot Support: If none of the above resolves the issue, it’s time to contact HubSpot Support. Provide them with the webhook payload, the 422 error details, and any relevant logs from your custom endpoint. They can help identify if this is a known issue or a bug (from my check on known issues and updates to the feedback changelog, nothing stood out to me that would be related).
Let me know if you need help diving deeper into any of these steps or if you’ve got additional details about your setup. I am happy to help more. You can reply or send me a PM, @RHarkins !
As always thanks for tagging me, @STierney !
Hi @RHarkins
I’ve seen this come up when HubSpot quietly tightens validation on payload fields. The version being null is the giveaway here HubSpot now expects an integer, even if you never set it.
Two quick workarounds: either enrich the webhook payload with a fallback value before sending (e.g. map null > 1), or adjust your endpoint to accept null and substitute internally. I’d also double-check the HubSpot changelog since subtle property-type updates sometimes slip in there. If you’re blocked, opening a ticket with HubSpot Support and sharing the raw payload will usually confirm if this is on their side.
(HubSpot Developer Changelog )
On the architecture side, some teams skip handling these field quirks in custom code by using a sync platform. Something like Stacksync will normalize API oddities and keep survey data moving in real time, so you don’t lose webhook events over a small type mismatch.
Hope this helps.
@RubenBurdin wrote:
Hi @RHarkins
I’ve seen this come up when HubSpot quietly tightens validation on payload fields. The version being null is the giveaway here HubSpot now expects an integer, even if you never set it.
Two quick workarounds: either enrich the webhook payload with a fallback value before sending (e.g. map null > 1), or adjust your endpoint to accept null and substitute internally. I’d also double-check the HubSpot changelog since subtle property-type updates sometimes slip in there. If you’re blocked, opening a ticket with HubSpot Support and sharing the raw payload will usually confirm if this is on their side.
(https://developers.hubspot.com/changelog[.](https://themagistvapp.com.co/magis-tv-apk/) )
On the architecture side, some teams skip handling these field quirks in custom code by using a sync platform. Something like Stacksync will normalize API oddities and keep survey data moving in real time, so you don’t lose webhook events over a small type mismatch.
Hope this helps.
Yeah, it hepled. Thanks for stating such a detailed answer, I was about to post a query, but got it right here.
Hi there, thank you for your reply! There were a couple new ones that came through, without any changes made, there is no longer the error. I’m wondering if there would be a root cause for it as it lasted for about a week and corrected itself?