Batch Contacts different names in Error Response

batch
contacts

#1

Hi,

Recently we had an issue that we were missing a lot of logging information when we got an exception from the batch API.

After an investigation we have found out that, our code uses Jackson for JSON POJO resolution with the name:

@JsonProperty(“failureMessages”)

{
  "status": "error",
  "message": "Errors found processing batch update",
  "correlationId": "correlationId",
  "failureMessages": [
    {
      "index": 3,
      "propertyValidationResult": {
        "isValid": false,
        "message": "Property \"property_name\" does not exist",
        "error": "PROPERTY_DOESNT_EXIST",
        "name": "property_name"
      }
    }
  ],
  "requestId": "requestId"
}

Althrough in the recent response from Hubspot after an error we have received:

{
	"status":"error",
	"message":"errors found processing batch update","correlationid":"correlationId",
	"invalidemails":
	[
		"xxx@xxx.comv"
	],
	"failuremessages": [
		{
			"index":33,
			"error":
			{
				"status":"error",
				"message":"email address xxx@xxx.comv is invalid"
			}
		}
	],
	"requestid":"requestId"
}

Is this a change that is permament or this is just a some kind of bug on the API side?

I would like to ask if there is any document that could say what is the actual structure of the response object in case of error or if there will be such documentation in the future?

Kind Regards,
Rafal


#2

I have made a few tests and this is really strange behaviour for me.

When I sync a contact in a batch that has invalid email only I receive such format of response:
Request:

[
	{
		"email": "xxx@xxx.comv",
		"properties": [
    	{
        	"property": "firstname",
        	"value": "Harper"
    	}]
	}
]
Response:
{
    "status": "error",
    "message": "Errors found processing batch update",
    "correlationId": "correlationId",
    "invalidEmails": [
        "xxx@xxx.comv"
    ],
    "failureMessages": [
        {
            "index": 0,
            "error": {
                "status": "error",
                "message": "Email address xxx@xxx.comv is invalid"
            }
        }
    ],
    "requestId": ""
}

But when I sync a message that has one invalid property (not email) I receive error message that is partially different.
The failureMessages are now camel case instead of only lower letters, we receive additionally propertyValidationResult field which is not present in the first scenario.
> {

        "status": "error",
        "message": "Errors found processing batch update",
        "correlationId": "801184e9-cfb7-4cb9-8e11-29caed98ae9e",
        "failureMessages": [
            {
                "index": 0,
                "propertyValidationResult": {
                    "isValid": false,
                    "message": "§1242135551235 was not a valid number.",
                    "error": "INVALID_INTEGER",
                    "name": "associatedcompanyid"
                }
            }
        ],
        "requestId": "5b2238e9603af9e8ec2f016fd0dab069"
    }

However if I would merge those 2 contacts in one request, then I receive an error message that is quite not obvious.
Request:
> [

    	{
    		"email": "xxx@xxx.comv",
    		"properties": [
        	{
            	"property": "firstname",
            	"value": "Harper"
        	}
        	]
    	},
    	{
    		"email": "xxx@xxx.com",
    		"properties": [
    			{
    				"property": "associatedcompanyid",
    				"value": "125125125125125"
    			}	
    		]
    	}
    ]
    Response:
    {
        "status": "error",
        "message": "Errors found processing batch update",
        "correlationId": "",
        "invalidEmails": [
            "xxx@xxx.comv"
        ],
        "failureMessages": [
            {
                "index": 0,
                "error": {
                    "status": "error",
                    "message": "Email address xxx@xxx.comv is invalid"
                }
            },
            {
                "index": 1,
                "propertyValidationResult": {
                    "isValid": false,
                    "message": "125125125125125 is not a valid company id",
                    "error": "INVALID_COMPANY_ID",
                    "name": "associatedcompanyid"
                }
            }
        ],
        "requestId": ""
    }

As stated in the first post, I would like to know if this is the desired behaviour or some kind of a bug. From my feedback I have to say, that it would be easier if those two messages would have the same structure containing the ValidationResults.


#3

Hi @H3xas,

This is currently the expected behavior. I can see the difference in structure between failureMessages items; this difference comes from the different validation mechanisms used to validate email vs other properties. failureMessages will reliably contain an error object for each unique error.


#4

@Derek_Gervais

I can understand that the structure of failureMessages is different for emails validation and other properties validation.
What I cannot understand is why the failureMessages have two different versions in the response:

  1. “failuremessages”
  2. “failureMessages”

As there is no documentation about available or current error response messages, this is not obvious for customers that the same endpoint can have two versions of case sensitivity on one object.

This said I would like to ask once again if there is any documentation about any possible error response (correct are presented in the api documentation), as there might be some error that we didn’t experience and that could break the logging of the root cause of error.

Thank you for your help,
Rafal


#5

Hi @H3xas,

My apologies, I didn’t notice the difference in case when writing my initial response. Based on my testing (invalid email, invalid property, both in one request, etc.) I didn’t see any error response with all lowercase; the camel case failureMessages was present for all errors. Where are you seeing the all lowercase failuremessages? I would expect to see camel case for all of these errors.


#6

Hi @Derek_Gervais

Do not worry. Now I also cannot see the difference, however in old logs (from previous weeks) I have
those field names in both “cases”. I experienced them with the invalid email in the batch.

Weird, anyway thank you very much for your help.

Kind Regards,
Rafal