i'm trying to update a contact, and I'm trying to adhere as best as I can to the example XML found on this page:
Here is my XML:
<id>http://api.constantcontact.com/ws/customers/[CUSTOMER NAME]/contacts/[CONTACT ID]</id>
<title type="text">Contact: [CONTACT EMAIL]</title>
<Contact xmlns="http://ws.constantcontact.com/ns/1.0/" id="http://api.constantcontact.com/ws/customers/[CUSTOMER NAME]/contacts/[CONTACT ID]">
<ContactList id="http://api.constantcontact.com/ws/customers/[CUSTOMER NAME]/lists/[LIST ID]"></ContactList>
I'm receiving a 409 Conflict error in response to my API call. I'm also using RESTClient 3.2.2, and I get the same 409 Conflict error, but nothing further to go on really.
Note: This account's username is an email address. I doubt this has anything to do with the problem, but thought I'd mention it. Let me know if I should be doing something special with the username (like HTML encoding, etc.), but the Contact add is working, and I'm using the same syntax for both API calls in this regard.
Please let me know what's wrong with my XML above. Thanks!
In your XML, are you using an ID in the ID string of an already existing Contact? Are you doing a POST or PUT request and what is the URI that you are making the request against? Are you trying to add a Contact with the same email address as one that already exists in your account (keep in mind, removing or unsubscribing a contact keeps that email address on your account)?
Thanks for the response, Dave. I actually figured out the problem, but thought I'd respond to close the loop and offer up what I found in case it helps someone else who may have a similar situation.
To answer your questions:
"are you using an ID in the ID string of an already existing Contact?" <-- Yes; the ID is verified with a lookup call that precedes this one.
"POST or PUT" <-- Using POST for adds (but we weren't having issue with this); using PUT for updates.
"Are you trying to add a Contact with the same email address as one that already exists" <-- We weren't having a problem with any adds; we were only having issues with updates.
ROOT CAUSE: After much experimentation, I stumbled across the root cause. The problem was that the username is an email address in this case.
Although the add call was working fine without url encoding the '@' in the username, the update call was blowing up due to it.
SOLUTION: I url encoded all '@' in the username where it was being specified in a url. I did NOT url encode it where it is specified as a username for authentication purposes.
That fixed the problem. You might want to examine why there is a difference in behavior between how the add call handles emails (specifically '@') in the path vs how the update call handles them.
It seems to me that the add call makes this conversion when it sees it, but the update does not. If that is the case it'd be nice if the update handled this conversion, too. That would be one less thing that might throw off a developer for future integrations.
Thanks for the update Eric. We will look into this. Want to set correct expectations, we are unlikely to update the v1 API with a fix for this though unless we identify a lot of failures around this case. The v2 API no longer requires username in any way for the requests and has eliminated this problem (an many others around using username in a URI).
Please help in "There was a conflict between the supplied data and the existing resource" error.
I am using constant contact php-api and I am getting the above mentioned error, but it does not occur while creating a new contact while the same error occurs when I am updating a contact (when confirmed opt-in is on he has confirmed the subscription). Also I dont get any error whether it is adding a new contact or updating an existing contact while the Confirmed opt-in is not used. I have already checked the email problem its related to email duplication.Dont know what to do, Please help me.
Posted a response on some of your other posts. This is not related to the original topic but we did mention this defect in our May release notes: http://developer.constantcontact.com/docs/release-notes/may-2014-rel-notes.html. We are working on fixing this defect now and hope to have it in a future release.