We all started somewhere! Share your experience on the Get Advice: Let's Get Started Sweepstakes thread and be entered to win a $100 credit on your Constant Contact account.

Authentication Deprecation and UK Access to Developer Site


Authentication Deprecation and UK Access to Developer Site



I've just started some development on Constant Contact and had a few questions.


Before I ask them, I appear to be having problems accessing the developer.constantcontact.com site from the UK, the page appears to re-direct (to http://developer.constantcontact.com/uk/developer/index.jsp) and fail - is this just me?


Looking at your recent posts about authentication, and the push towards OAuth 2.0 - your 'Authentication Overview' page indicates that both the basic/over https and OAuth 1.0a methods are deprecated.


Could you just clarify that if I develop something using the numerous examples and documentation on the Basic/HTTPS method if it will cease to function once it is 'removed from the product'?


Many thanks






We aren't recieving other reports of connectivity problems with our developer site right now from any location, but considering the nature of the internet, you may be the first to experience a new issue. Are you using a bookmark or link from a search engine to access the site?  If so, what happens if you simply type developer.constantcontact.com into your browser address bar?


We are moving progressively to OAuth 2.0 and recommend developers update their applications to this.  Basic and OAuth 1.0a are deprecated in that we are actively developing and supporting OAuth 2.0. Currently, we intend to discontinue Basic Authentication, and may also discontinue OAuth 1.0a. When discontinued, intergration that rely on these authentication mechanisms would cease to function until updated to OAuth 2.  We do not currently have a specific timeframe in which these things will occur, as this will depend on development activities whose timeframes may shift.



Mark Coleman
Support Engineer

Hi Mark


Thanks for the quick reply, really appreciated :)


I've tried all sorts with the URL, had to go via a US proxy in the end to stop the UK redirect... all I got was:


Firefox has detected that the server is redirecting the request for this address in a way that will never complete.




May just be a gremlin in my machine...!


Thanks for the details on the migration to OAuth 2.0 - I think the thing that threw me a little is that with all the questions about the basic authentication on the forums there's little mention that people should really shift to OAuth 2.0. I've actually got things working to a certain extent using basic, but like the idea of building something that will hopefully stand the test of time and not fail at some undetermined future date :(


I'm still grappeling with the PHP class you've very helpfully put together, it's a huge time saver thank you.


I'm trying to add a content to ONE specific 'new' list, which I can do, but am struggling a little to handle individuals who may be on other lists but not the new one (and adding them), and the errors that occur if the user is already on the new list and they try and submit their data again... both of which are likely to happen.


I sounds like Firefox security settings are working to prevent potentially malicious redirects by websites, and unless you can changes those settings, the US proxy may be your best bet.


The beginnings of our move toward OAuth 2 were fairly recent, so it's likely there are still a lot of forum posts in which we provided information about basic authentication that do not include encouragement to shift to OAuth 2. I try to encourage developers to make the move, but at present Basic Authentication is still functional and allows some initial development and concept testing before one delves into an OAuth 2 implementation. Once developers grasp the authorization and token request flows from OAuth 2, it's more simple to implement programmatically, so we believe it's a good balance of security and ease of use.


In our system, contacts (email addresses) are permanently associated with an account, once added to any list in the account, even if subsequently removed from active lists or unsubscribed from all account mailings (see this previous post, which describe our contacts data model). This allows us to enforce the wishes of your contacts if they request not to recieving your mailings, and make sure we (and you) are incompliance with anti-SPAM laws in the U.S. and other countries.  In our Contact data model, lists are in turn attributes of the contact. Based on HTTP stanards, our API uses POST requests to create new contacts in an account, and PUT requests to update the details for contacts already associated with an account.


Because update requests replace current contact details with new ones provided, when you make a PUT request to update contact lists for a contact, you should include all contactlists that the contact should be on after the request is fulfilled.  As such, the best flow when you need to add to the contact lists for a contact, is to get the current details for the contact, then add the additional lists to the current set of lists there, and then use the object to submit an update request for the contact.


I hope this is helfpul. Let us know if you have additional questions.

Mark Coleman
Support Engineer
Developer Portal

View API documentation, code samples, get your API key.

Visit Page