Just starting to tear my hair out (and there's not much left!) so resorting to the forum to help me out with this.
A client of mine is using Campaign Monitor to send out post signup emails for a subscription service (via autoresponders). The dates for the auto responders are set using custom fields for the subscriber (the exact date for post-signup emails being calculated when a user signs up).
Now, said client, want to cancel some of the actions if the subscribers meets certain conditions with service.
I am trying to remove the value of a custom field for a given subscriber, and this is where I am coming unstuck. Whilst I can use subscriberAddWithCustomFields to change any of the custom field values, I cannot return a custom field back to an empty value. It's not a huge issue, tbh, I can successfully set a date custom field to a date in the past, which prevents the email coming out - it just seems a little 'hackish' to me, and it also confused my client when they view the individual subscriber data within Campaign Monitor.
Have tried passing the following as values to the custom field (0, null, false, "", " ", "0000-00-00"), however it seems that any invalid date simply leaves the field in it's present state.
Any help appreciated.
I'm afraid there currently isn't a way to clear the value of a date custom field via the API. Currently, we ignore any null or blank values for any custom field updates, and any invalid date values will also be ignored.
I've put in a bug report to see if we can come up with some way of clearing the value of a date custom field. We'll get back to you here when it's been implemented.
Ah, bizarrely I'm almost pleased by that - spent long enough thinking I'd been overlooking something obvious ;-)
Am I safe to assume that if a date is set 'in the past' (and autoresponder using it is set to 'Send on Date') that autoresponder will never trigger (i.e. it won't suddenly realise that something should have been triggered but hasn't and send them all out in 1 go).
All I need to do then, is simply explain to the client that they need to interpret dates in that past as 'Cancelled'.
Thanks for filing a bug report - it would be nice if the field could be empty altogether (from a reporting aspect) - but so long as the effect is the same, I can work with it.
Think I have come across the same problem.
Am I right to say that it is impossible clear custom data for any type of field for a subscriber via the API?
Emailed CM with this and they confirmed that you can't simply clear custom data.
I'm afraid there isn't a way to clear data like you are wanting, but you can overwrite it - either with "N/A" or sometimes it works to just import a double space " " to the value. It's a bit of a hack and the "is not provided" segments will not return those fields
I tried out the double space hack and it seems to work for text fields only.
Just following up on this old thread to confirm that it is possible to clear a date type custom field by specifying the value "0000-00-00" for a date type custom field.
This is something I've just come up against. I have situations where a customer would like to clear their value. I guess making a change like this to the API would affect a lot of people's code, but I think it would be good to allow previously set custom fields to null or blank values.
We've actually recently allowed clearing of values when updating a subscriber via the API.
Quoting from the documentation:
To clear the value of a custom field, pass a parameter of Clear with a value of true along with the custom field name/value. To remove a specific Multi-Valued Select Many option, pass the option name in the Value field along with the Clear: true parameter. To clear all values of a Multi-Valued Select Many field, pass an empty Value along with the Clear: true parameter. Alternatively, Date type custom fields may be still cleared by passing in a value of "0000-00-00"
Hmmm... I've tried a few ways without success. Can I confirm I'm doing this right:
Here is some debug output. In the middle, I've inserted the output of my PHP array. I'm trying to clear the "State" custom field:
13:07:41 - Cmonitor: Creating wrapper for https://api.createsend.com/api/v3/ 13:07:41 - Cmonitor: Using cURL for transport 13:07:41 - CS_REST_SERIALISATION_get_available: Getting serialiser 13:07:41 - Cmonitor: Using native json serialising Array ( [EmailAddress] => email@example.com [Name] => Jay [Resubscribe] => 1 [CustomFields] => Array (  => Array ( [Key] => School [Value] => School for Gifted )  => Array ( [Key] => Postcode [Value] => 0345 )  => Array ( [Key] => State [Value] => [Clear] => 1 )  => Array ( [Key] => Position [Value] => Classroom Teacher, School Support Staff, Student Teacher )  => Array ( [Key] => Reason [Value] => Postcard )  => Array ( [Key] => Source [Value] => Freebies ) ) ) 13:07:41 - Cmonitor: Making POST call to: https://api.createsend.com/api/v3/subscribers/xxxxxxxxxxxxxxx.json 13:07:41 - CS_REST_CurlTransport: curl+zlib support available. Requesting gzipped response. 13:07:42 - CS_REST_CurlTransport: API Call Info for POST https://api.createsend.com/api/v3/subscribers/xxxxxxxxxxxxxxx.json: 396 bytes uploaded. 33 bytes downloaded Total time (seconds): 0.970483 13:07:42 - Cmonitor: Call result: array ( 'code' => 201, 'response' => '"firstname.lastname@example.org"', ) CS_REST_Wrapper_Result Object ( [response] => email@example.com [http_status_code] => 201 )
I've tried setting State's value to NULL instead of "". I've tried setting Clear to "true" as a string instead of a native BOOLEAN. No mattter what, the old state seems to stay there.
Am I missing something obvious? What can I check?
We have just released an update to the API to allow clearing custom fields for existing subscribers. The updated doco is here: http://www.campaignmonitor.com/api/subscribers/#updating_a_subscriber
Hi David, I've read, and believe to have followed that documentation. Doesn't my code sample correctly implement it as documented?
You're right - the procedure for removing the custom field value was inexplicably missing from the production databases. Give it a bash now :)
Yay! Works great now. Thank you.