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 email@example.com.
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.
Have updated that example URL provided in the previous PM. It now includes:
1. Link to a txt file of the JSON payload returned from CTCT with GET request.
2. Link to a text file of the JSON payload submitted back to CTCT with the PUT request for each Contact.
3. A display of the ColdFusion source code for the page - with extensive comments detailing each step.
4. Output of orginal Contact data and updated Contact data after PUT requests.
As you will see, we only submit via PUT the following JSON elements for each Contact:
We don't submit any other Contact meta data JSON elements (address, city, state, etc.) with the PUT request and the API does not alter those values - contrary to the API documentation.
The API is actually acting like a POST request for almost all data elements, it doesn't for the JSON Lists & Status values. If Lists are not submitted, it removes the Contact from all assigned Lists. If Status is not submitted, it changes to Contact from Active.
This is all intended for the final goal of using the new CustomField naming feature in the new Contacts Management system. Specifically enabling us to create and use our own unique custom fields and not worry about conflicts with any existing data in the default CustomField(1-15) fields.
Is there any status updates on the new customfield naming feature?
View API documentation, code samples, get your API key.Visit Page
The holidays have come and gone. For many seasonal businesses, this means the rush of shoppers has decreased as well. Instead of turning off the lights and waiting for spring, make your email marketi...See Article