I'm running into an issue where contacts have been created with characters that are not valid in XML documents. My particular situation is contacts have names containing ^Z or ASCII 26. These bytes are not valid in XML, but are being sent unencoded causing XML parse errors when the XML is processed.
The problematic endpoint is https://api.constantcontact.com/ws/customers/kiet.tran/contacts. In particular the contact at http://api.constantcontact.com/ws/customers/kiet.tran/contacts/130 has the skunky data.
I can't limit/correct the data going into constant contact, as I develop an integration used by a number of constant contact users. I would expect Constant Contact to generate well formed XML even when there is invalid input. If it would help more I can paste a shortened response XML somewhere.
We have traditionally expected the XML that is sent to us to be already encoded (in particular you must encode any < and > in the contact details for the payload to be accepted), but I would be interested in the characters that are causing you trouble. Either the specific characters or the XML with your username removed would be great. Thanks in advance.
Also, if you don't mind, why are the characters causing you trouble? What parsing system are you using, if it's a parsing issue?
API Support Specialist
The issue I'm having is not with XML requests that I'm sending it is with XML responses I'm receiving from Constant Contact. The problematic bytes are 0x1a or ASCII 26 a.k.a ^Z or SUB. I've tried parsing the responses with both PHP's built-in SimpleXmlElement, and Python's lxml libraries and am unable to parse the response data I'm getting.
The characters are causing errors as they are invalid bytes in XML 1.0 documents, this causes all the standard XML parsers we use to throw errors.
http://pastie.org/7709012 contains the problematic data. The name shows as invisible data as the bytes are non printable data, but viewing the raw paste data into a reasonable text editor will display the bytes.
Thanks for pointing that out. We will open a defect on this and look into it. Please keep in mind, we have released a new version of our API, found at http://developer.constantcontact.com, that will not have this problem. Since this is a defect with charater encoding in our V1 XML API, we can not give any time line on when this will be fixed.