"Unrecognized property" updating contacts

API Q&A
#1

Hello,

Currently if I retrieve a contact via REST api, change the contact’s name and send this same object to the update contact request I receive “Unrecognized property” with the following fields: email_opted_in, last_updated, date_created, tag_ids, email_status and id.

When I go to the PATCH api docs (https://developer.infusionsoft.com/docs/rest/#!/Contact/updatePropertiesOnContactUsingPATCH) some of these fields are present on the sample request body.

How can I identify the fields that are returned on the GET request that should not be sent on the PATCH body? Should I create a field whitelist?

Thanks,

PHP SDK REST API update note error
#2

All the fields you mention in the message are read only. You cannot write them to the contact but rather, they are only generated by the system itself.

#3

With yesterday’s release, the API Team made an improvement to the REST API documentation for the Contact resource. The Contact resource body samples now accurately indicate which properties are available for each request and response.

Simultaneously, we unintentionally caused previously valid requests that carried certain ignored properties to fail. For example, if a request to create a Contact were to contain an id or email_opted_in it would be unintentionally rejected with a status code of 400.

The API Team is presently fixing the unintended behavior. We expect it to be released and resolved today.

The intended behavior is:

  • to have the API documentation for the Contact resource correctly reflect what properties are allowed for requests
  • to have that API documentation accurately reflect what properties are returned in responses
  • to continue to silently ignore properties in requests that were previously ignored and not reject the request as a whole
1 Like
Contact create related Rest API generate a Error
Adding Contact, returns 400 Bad Request, "Unrecognized property: email_opted_in"
API Additions and Changes 2018-04-09
#4

Hi,
We still receive the error.
Any updated estimate on when the fix will be deployed?
Thanks,

#5

@Terry_Kim The fix was deployed successfully that same night (America/Phoenix). Would you check your web app and let me know what version you have? It should be at the bottom of any of the screens, in small typeface, and read something like 1.69.0.114-hf.

#6

Thanks for your response. This is what we have on our production app.

Screenshot%20from%202018-04-06%2001-57-53

We still get errors like

[MESSAGE] Request failed with status code 400 :: [RESPONSE_BODY] {"message":"Unrecognized property: tag_ids"}

but we didn’t change anything on our side.

#7

@Terry_Kim Thanks for confirming the version and for the additional detail. I will need to dig in deep and do some research on the change made to that section of the API to understand what happened.

In the meantime,

  • post a copy of the URL and payload of your request (it will help me with the research)
  • and, if you can manage it, I’d highly recommend removing tag_ids from your request payload
#8

Thanks for your investigation.

post a copy of the URL and payload of your request (it will help me with the research)

the URL is /crm/rest/v1/contacts/XXX

We send a response body from this endpoint /crm/rest/v1/contacts?limit=1&email=XXX&access_token=XXX as the request body.
We add a couple of fields like opt_in_reason. I’ll post the entire request body as soon as I get the data.

and, if you can manage it, I’d highly recommend removing tag_ids from your request payload

We’re planning to remove all unnecessary fields from the request body in the near future. But it would be great if the endpoint keeps working as before.

Thanks!

#9

I’m in agreement; my goal is to accept, silently ignore, reject through the Contact resource whatever we were doing before.

Oh, it’d be helpful to know which HTTP verb you’re using, too. There may be something unique to one vs another.

#10

Sorry for the delay.

We use GET for /crm/rest/v1/contacts/XXX

and PATCH for /crm/rest/v1/contacts?limit=1&email=XXX&access_token=XXX

I hope this helps your investigation.

Thanks!

#11

I went back to the app version just prior and found the following.

Request

If I make this request (excerpt):

PATCH /crm/rest/v1/contacts/3 HTTP/1.1
Accept: application/json, */*
Accept-Encoding: gzip, deflate

{
  given_name=Mike,
  "tag_ids": [
        1,
        2,
        3
    ]
}

Old Response

Then I receive this response (excerpt):

HTTP/1.1 400 Bad Request

{
    "message": "Tags can't be added or removed through this object"
}

A review of the VCS history for the associated code shows that this particular check, response status code, and response message has been in place since Nov., 2016.

New Response

If I make the same request to the new version, I receive this response (excerpt):

HTTP/1.1 400 Bad Request

{
    "message": "Unrecognized property: tag_ids"
}

Summary

It’s late, so I might be missing something… but, I think it’s safe to say:

  • we’re doing the same check as before (tags not allowed)
  • we’re sending the same response status code as before (400)
  • but, we’re sending a different message ("Unrecognized property: tag_ids")

@Terry_Kim, do you know if you have a special check to look for or ignore "Tags can't be added or removed through this object" that may not be set up to cope with a change in message?

#12

@mike.christianson

Thanks for the update.

I don’t think we ignore that message.

As we mentioned above, we send a response body from GET /crm/rest/v1/contacts/XXX as the request body to the patch endpoint.
I checked the following document and it returns tag_ids in the response body.
https://developer.infusionsoft.com/docs/rest/#!/Contact/listContactsUsingGET

Is this tag_ids field new from the previous update?

#13

Hmm… :thinking:

No, it’s not new, but there’s a caveat. We respond with a populated array of tag_ids when getting an individual contact (/contacts/{id}). However, when getting a list of contacts (/contacts) we respond with an unpopulated list of tag_ids:

I wish I could say we goofed but it looks like our over all behavior is unchanged except for the message. We’ve been rejecting create/update requests with tag_ids for well over two years.

@Terry_Kim I’m stumped as to why you might still be having issues. :disappointed:

#14

@mike.christianson

Thanks for the update.
I think we’ll just have to change our code as it seems difficult to find out the reason.

I’ll post the update if we find out something.

Meanwhile, can you let me know if there is a place to subscribe to announcements for this type of updates?

#15

:+1:

API release notes are regularly posted here, in the API Q&A forum. They’re tagged api-update.

1 Like
#16

We’ve eventually pushed the fix and it seems to be working without error.
Thanks for your support.

2 Likes