I'm using the getListMembers() in the PHP library and it's working fine, except that the "updated" field is returning today's date instead of the date the list member was updated. The issue doesn't seem to be in the PHP library, but the XML being returned.
If I debug the code a little, here's an example of a list member's XML code that is being returned for one member.
<link href="/ws/customers/USERNAME/contacts/200535" rel="edit"></link>
<title type="text">Contact: email@example.com</title>
<ContactListMember xmlns="http://ws.constantcontact.com/ns/1.0/" id="http://api.constantcontact.com/ws/customers/USERNAME/contacts/200535">
If I do a search for the same email in Constant Contact, the date says it is 6/5/2012. This is happening for anyone returned by getListMembers(). I keep getting today's date.
Any thoughts on this?
It looks as though each individual contact node from that call populates its own "updated" time. It goes up by about a split second for each one. You can definitely get the accurate updated time by querying the contact directly.
I'll discuss it with the developers to be sure, but this does look like a bug in our system. However, with the development of our next version of the API, I'm not sure if this will be fixed, or put on the backburner to leave time for the new project. I would suggest querying the specific contact URI for the correct updated time for the contacts you need.
If you'd like a follow-up on this, feel free to send us an email at firstname.lastname@example.org, and we can let you know what comes out of this.
Thanks for the response. I can give querying each contact a try. The main reason I wanted to do this is to pull in each week the list of new people from the Do Not Mail list. The trouble is that I don't know how many pages to pull from the list without knowing what date they were added.
I guess I could pull a page's worth of data, query each contact to get the dates, and if the dates are still within this week, pull the next page and repeat.
That's going to create 51 API calls per page though (1 to pull the 50 contacts, 50 per contact) - which seems pretty excessive. Unless there's a way to query multiple contacts at once.
NOTE: I also tried using searchContactsByLastUpdate() and passing a date such as "2012-06-13T00:00:00.000Z" returned very random results from over a year ago... not sure if that isn't working properly either.
I just gave a direct test to our API with searching by last update, and the responses seemed to be accurate. It's possible that the issue with searchContactsByLastUpdate() is an issue with the wrapper, and not the API itself. We can definitely look into this as well for you.
Here is some debugging on what the wrapper is sending/receiving.
The first entry returned is for someone who opt-ed out on 8/22/2011 12:57 PM - definitely not since 6/14/2012.
Is there anything in the XML returned that looks odd / would explain this?
<title type="text">Contacts for Customer: USERNAME</title>
<link href="contacts" rel="self"></link>
<link href="/ws/customers/USERNAME/contacts?next=234830&updatedsince=2012-06-14T15%3A35%3A37.566Z&listtype=do-not-mail&ous=2012-06-14T00%3A00%3A00.000Z" rel="next"></link>
<link href="/ws/customers/USERNAME/contacts?updatedsince=2012-06-14T00%3A00%3A00.000Z&listtype=do-not-mail" rel="first"></link>
<link href="/ws/customers/USERNAME/contacts?updatedsince=2012-06-14T00:00:00.000Z&listtype=do-not-mail" rel="current"></link>
<link href="/ws/customers/USERNAME/contacts/236416" rel="edit"></link>
<title type="text">Contact: email@example.com</title>
<Contact xmlns="http://ws.constantcontact.com/ns/1.0/" id="http://api.constantcontact.com/ws/customers/USERNAME/contacts/236416">
<Status>Do Not Mail</Status>
The XML looks correct, and the return seems valid, but that's without seeing your account info from the back end. If you'd like, you can email or PM me your username, and I can look into the info more closely.
I looked in your account and the data being returned through lastupdatedsince appears to be correct. On 6/14/2012 an upload of new contact information was put through, which updated the contact information of over 500 people on your Do Not Mail list. While that contact may have opted out on 2011, their information was updated again on the 14th.
When you do those types of contact updates, we still will update personal information such as first name or last name. Just because they are currently opted out doesn't mean that they will always be opted out (they could resubscribe for example) and they may also interact with you in other ways, such as taking a survey or registering for an event, and that will correctly have the most recent updates of information.
Also, as a clarification on the getListMembers <Updated> node timestamp, this timpstamp represents a timestamp of the last time we refreshed the data associated with the GET request in question. It will always show the most recent timestamp of the cached data, not the actual recency of the data included in the collection.
I definitely understand the value of having the <LastUpdatedTime> returned as part of the Contact records in the list members collection. In our next version of our API, which Nick mentioned we are hard at work developing, we're doing a lot of work to make sure whenever we return data it's complete and all valuable data is included. I know this doesn't help you with your immediate problem, but if you use the lastUpdatedSince feature you can certainly get the data you're looking for.
I am experiencing the same issue while attempting to do the same operation as Justin C - retrieving the Do-Not-Mail list periodically. It is not reasonable to cycle through over 100k records (in 50-per-page), when it seems quite simple to do a differential pull using the LastUpdated field as the API documentation specifies is possible.
When you expect this issue to be resolved?