I write again to please ask you to return the field that you used to have that allowed a list owner to dump in email addresses for removal. This process was SO simple and so easy and now, instead this is what I have to do:
1) Upload list to be removed.
2) Find account is locked down because the upload has triggered a list review - go through process of list review.
3) Create duplicate list to temporarily remove the people I don't want to mail this particular message to.
4) Call Constant Contact in order to remove them using the "add to list" function because, due to a bug in the system I cannot see the lines and check marks on the boxes (and, yes, I have tried different browsers, 3 to be precise).
5) Go through the painful process of explaining to a support rep why I am calling and then talk them through what I want done.
6) Then go through the even more painful process of removing the email addresses that I've just uploaded but without removing those that are already on a list, which involves deleting the list but keeping the contacts and then going to Advanced search to create a list of all those who are not on any list and removing them.
All that, and an hour of wasted time just because there's no ability to dump in email addresses to remove anymore!
... View more
On the email report titled: Your Latest Contact/Subscriber Activity, it would be very helpful if you could include the reason somebody opts out (if they choose to provide it).
This is particularly important for us managing our list of paying members as sometimes somebody will opt out of the emails intending to cancel their membership - in which case, if they have said that this is the reason, we want to action this cancellation as soon as possible. But it's not possible to assume that everybody who opts out of emails wants to cancel their membership because more than half of those who opt out do so accidentally. So seeing a message would give us a clear indication to cancel, and not seeing a message would allow us to then follow up with the member.
... View more
Following up on my earlier comments and those of others about how unwieldy it now is to remove people from lists (instead of just copy/pasting into the remove field having to create a whole new list) - not only is this a pain to do but, because your pricing system automatically resets to the max number of contacts on the list, irrespective of whether those people have been mailed, I end up in the wrong pricing category and have to call in to get it reset.
For example - we maintain 3 different accounts with Constant Contact as it is not appropriate for those on one list to have the option of subscribing to some of the other lists (and the last time I checked there was no way to compartmentalize within an account thus we have to keep them separate.) But there is some overlap between these lists so sometimes I have to de-duplicate before mailing - and to do this I now have to import emails from one list into another (instead of just pasting into the remove field). It is this process that leads to the accounting issue.
... View more
That does indeed seems to be the case. It is difficult to tell when you allow people to manage their own subscriptions; but we have not come across any problems with people adding new accounts, or with our deactivation/removal of a subscriber. However, we are changing the software this week to record the calls made to your API s we can manually check failed transactions.
... View more
The error we see is when a subscriber is resubscribing (status="Do Not Mail" to status="Active"). I have not identified a time pattern. I tested the API manually at around 12.00PST today. Using identical code, 4 subscribers who had previously tried to resubscribe went through fine, one required two tries, one required 3 tries. I have also spent a few hours this afternoon (aftyer your reply) working on it, and can find no consistent pattern. Below are example XML dumps. To enable me to better see what is going on, I added the API response into custom field 1 for the dump, not sent to the API!. As you will see, this time it took 2 tries. When the opt-in works, I get "204 No Content" as a response. If it does not work, I see "400 bad request" The testing process I used this afternoon was to manually go onto CC, mark a subscriber as "Do Not Mail", and attempt to resubscribe thoguh the API. First try required two attempts (screen refreshes). Went back onto CC, marked as "Do Not Mail". Resubscribed - worked first time. Repeated. Worked first time. Repeated. Took 3 tries. <sigh> I also used the "get" command to get the subscriber details before and after the API call to see what was going on.....no smoking bullet! Interestingly, after I have successfully resubscribed a contact, I generally search for them in Constant Contact to recheck the status (although through the "get" indicates they are Active). Sometimes they come up in CC as "Active"; sometimes as "Do Not Mail". I just searched for a contact who was noted in the search screen as "Do Not Mail", clicked on the name for more information, where the contact was marked as "Active". Searched again: "Do Not Mail". Generally logging out and logging back in helps....wild thought, I assume your servers are in a cluster, could one node be out of synch somehow? Could this have something to do with the intermittent problem we are seeing? Below is a recent dump of the XML file. To better problemsolve, in the custom field 1 (in the dump not sent to the API) I included the response. id http://api.constantcontact.com/ws/customers/xxxx/contacts/xxxx xmlns http://ws.constantcontact.com/ns/1.0/ Status Do Not Mail EmailAddress email@example.com EmailType HTML Name xxxx FirstName Paul MiddleName LastName xxxx JobTitle CompanyName HomePhone WorkPhone Addr1 Addr2 Addr3 City StateCode StateName CountryCode CountryName PostalCode SubPostalCode Note Member added from xxxx admin CustomField1 response: 400 Bad Request CustomField2 CustomField3 CustomField4 CustomField5 CustomField6 CustomField7 CustomField8 CustomField9 CustomField10 CustomField11 CustomField12 CustomField13 CustomField14 CustomField15 Confirmed true InsertTime 2011-01-05T21:37:35.648Z LastUpdateTime 2012-04-28T01:41:05.589Z OptInSource ACTION_BY_CONTACT ContactLists ContactList id https://api.constantcontact.com/ws/customers/xxxx/lists/xxxx ContactList id https://api.constantcontact.com/ws/customers/xxxx/lists/xxxx id http://api.constantcontact.com/ws/customers/xxxx/contacts/xxxx xmlns http://ws.constantcontact.com/ns/1.0/ Status Do Not Mail EmailAddress firstname.lastname@example.org EmailType HTML Name xxxx FirstName Paul MiddleName LastName xxxx JobTitle CompanyName HomePhone WorkPhone Addr1 Addr2 Addr3 City StateCode StateName CountryCode CountryName PostalCode SubPostalCode Note Member added from xxxx admin CustomField1 response: 204 No Content CustomField2 CustomField3 CustomField4 CustomField5 CustomField6 CustomField7 CustomField8 CustomField9 CustomField10 CustomField11 CustomField12 CustomField13 CustomField14 CustomField15 Confirmed true InsertTime 2011-01-05T21:37:35.648Z LastUpdateTime 2012-04-28T01:41:05.589Z OptInSource ACTION_BY_CONTACT ContactLists ContactList id https://api.constantcontact.com/ws/customers/xxxx/lists/xxxx ContactList id https://api.constantcontact.com/ws/customers/xxxx/lists/xxxx As I said, I can code things on my side to capture any 400 errors and simply resubmit the same information mutliple times, but it seems like a bit of a kluge.
... View more
In general the API works well, but recently we have noticed intermittent 400 errors. Generally a transaction goes through fine; sometimes we get a 400 error. Resend - sometimes goes through second time, sometimes third time. Always works eventually. I guess I can write some code to automatically resend (say) 5 times if I get a 400 error, but that seems like a kluge...any suggestions? It is difficult to post sample code as it is all dynamically generated..so would welcome suggestions. Do your servers send a 400 error if they are receiving too many requests? (BTW, we average perhaps 4 a day......so not too many!)
... View more