Am using the API(v2) to update contacts. Why is the LISTS json element required on all updates? Especially if the task only relates to updating ancilliary contact data (name, physical address, custom fields, etc) and does not impact current list assignments. The API sets the contact's status to REMOVED if the lists element is not supplied. This becomes an additional issue when the contact might be active but currently does is not assigned to any lists at the time of the API query/update.
When there are existing/assigned list(s), not problem. When none are assigned the contact then gets set to REMOVED.
The issue you're seeing is because the PUT request is a replacement request. It basically says "replace all of the Contacts current attributes and data with this data". If you send us a request with no lists, this is telling us to remove the Contact from all lists, which is why the Contact is then in a Removed state (I.E. not in any active lists and thus not active). This is how the PUT HTTP verb is designed to work and we have implemented it in the most predictable manner we could.
We are looking at ways to do partial updates, likely using the newly defined PATCH HTTP verb. This verb, unlike PUT, is designed to update an existing resource. This is how the HTTP spec has been designed to avoid unpredictable behavior. Sorry for any confusion on this!
Thank you for the prompt and detailed response. However, it doesn't quite jive with the API's actions. Specifically, the API does not overwrite other important contact fields (name, phone, address, etc) if they are omitted from an API PUT submission. Why so with Lists?
That sounds like a defect on our side. Will have our QE team take a look and see if we can get that fixed.
We did testing on our side and were not able to reproduce the behavior you described. When we leave entire fields out of the JSON payload, our tests have shown those fields correctly being nulled out on update. Is there a specific field and/or payload that you are sending that is able to reproduce this? If this is happening, we definitely want to get a bug open and get that fixed.
Where can I send a URL to you so you can see this happening?
For more detail, we are posting updates with new data back to the CustomFields via the PUT API call. Initial requests set a unique value used in newsletter links to identify the recipient/contact when clicked. After the link is clicked, we post back (via same PUT) different fields with data based on what occurred at the URL/page. That second PUT does not submit all the contact's fields, only the ones we are updating. All remaining fields - both custom and default (name, phone, etc) do not get over written.
You can either send it to me as a private message or email our support staff at firstname.lastname@example.org.
We haven't had any updates as yet, not been able to reproduce this behavior in any of our testing environments or production environment. The URIs definitely look correct and, provided your payloads are correct as well, you should be updating the contacts correctly. We will continue to test and see if we can reproduce. The only other thing we would ask for that could make this troubleshooting faster would be if you could reproduce this in a REST client of some kind, save the requests that reproduce this and send them over to us.
View API documentation, code samples, get your API key.Visit Page
We want to hear from customers like you about your favorite features and how they have helped your business or organization. Tell us by answering a few questions in...Read More