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 (Keap REST API) 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?
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.
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
@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.
@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
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.
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?
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.
