Is Oauth 1 depricated on Constant Contact? Should we be using Oauth 2?

Regular Participant

Is Oauth 1 depricated on Constant Contact? Should we be using Oauth 2?

Hi we are following the steps outlined here to support OAuth authentication for our app:


This was working correctly for some time, but now we are receiving the error message "The token is not an OAuth2 token".


Has there been a change put into place that has depricated this method of OAuth and now only OAuth 2 is supported? Are there any official documentation that explains this at all?




We are currently still supporting OAuth 1.0 but have had a few users report the same message you have seen.  Can you provide additional information about how you go this error such as:


  • OAuth library/develompent language?
  • Request type(s) you are making?
  • Are you sending the OAuth data as Headers or as Query Params?
Dave Berard
Senior Product Manager, Constant Contact
Regular Participant

We are using PHP, and using the oauth-php library from Google Groups:


We are attempting to make the request to<LOGIN>/lists using the token we received from the OAuth process.  This request returns the message "The token is not an OAuth2 token"


We are sending hte credentials as query parameters, so that our final url is:<LOGIN>/lists?oauth_consumer_key=<KEY>&oauth_nonce=<NONCE>&oauth_signature=<SIG>&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1311610089&oauth_token=<TOKEN>&oauth_version=1.0



After looking at this with our engineering group, we have found a bug with OAuth 1.0a support using Query Param options.  We are looking into this and hope to have a fix available in the near future. 


In the meantime, a simple workaround is to always send the OAuth Authentication data as Header values instead of Query Params.  This should be as simple as changing a flag in your OAuth library and will resolve the issues you are seeing until we have a fix in place. 


Thank you again for reporting this.

Dave Berard
Senior Product Manager, Constant Contact
Regular Participant

I try by replace the code , but it does't work yet . Please advise. 





$request_url  = $api_request->to_url();


              /* old code 

               $session = curl_init( $request_url );

               curl_setopt( $session , CURLOPT_RETURNTRANSFER , 1 );

               curl_setopt( $session , CURLOPT_SSL_VERIFYPEER , 0 );

               $response = curl_exec($session);

               if ( !$response ) {

                    echo "Unsuccess !"; exit;


               $error = curl_error( $session );

               curl_close( $session );



                /* new code */

               $params = array();

               $tmp = explode( 'lists?' , $request_url );

               $tmp_oauth = explode( '&' , $tmp[1] );

               foreach ( $tmp_oauth as $keys => $vars ) {

                         $cuts = explode( '=' , $vars );

                         $params[ $cuts[0] ] = urldecode( $cuts[1] ) ;


               $method = 'POST';

               $url    = $webServiceUrl;

               try {


                  $request = new OAuthRequester( $url , $method , $params );

                  $opts = array( CURLOPT_HTTPHEADER => Array("Accept: text/xml") );

                  $result = $request->doRequest( 0, $opts );

                  $response = $result['body'];


               } catch( OAuthException2 $e ) {

                     echo $e; exit;

If you are sending your request and still receiving a 400 - Bad Request error, I would imagine that the following line is not setting up the request with Headers instead of Query Params:


 $request = new OAuthRequester( $url , $method , $params );


I'm not familiar with the library you're using, so it will be hard for me to give you guidance on how to configure it.  We do have a fix that will be going out in our next release which should have this problem resolved Thursday (tenative date, subject to change). 

Dave Berard
Senior Product Manager, Constant Contact
Regular Participant



I believe there was a mistake in this set up. Currently we are using a standard cURL call to send the request to the constantcontact api.


Originally we built out the URL as a GET and sent it, which worked for some time. After, we then switch to POST with the same parameters but as a POST, but it is now returning the error "An authentication object was not found in the SecurityContext".


Is this what you meant by passing the request with Headers? Or are we in the wrong path with this?



In order to use Query Parameters for OAuth 1.0a, you would need to set the Content-Type to application/x-www-urlencoded-form.  This tells the server to expect the OAuth values and the data as query parameters.


The POST requests must be sent with a Content-Type of application/atom+xml, which will cause the server side OAuth to look for header values for all of the OAuth parameters.  For this reason, it will fail to find the OAuth values as they aren't set as headers in your scenario and will through a 401 error.


Since all POST/PUT requests require you to set it up as header values anyway, we're suggesting that you just set the code up to do the exact same for GET requests and that will get you around this problem.  You'll simply need to use code similar to this:


curl_setopt($request, CURLOPT_HTTPHEADER, $header_array);


That is how you would manually set the header array for the request.  I'm not sure if the library you are using provides a way to do that without having to manually create a header array and set it.  If you need help with that library, I would suggest posting on the project forum and seeing if someone can assist you with that.

Dave Berard
Senior Product Manager, Constant Contact
Regular Participant

Hi- we are still having problems setting this up, and I am slightly unclear as to what you have advised us to do.


We are not using any library to make this final call, but are attempting to do so with a manual cURL command.


Are you suggesting that we send all of the parameters: 


( oauth_consumer_key, oauth_nonce, oauth_signature, oauth_signature_method, oauth_timestamp, oauth_token, oauth_version )

as POST parameters, with the header set with application/atom+xml  ?   We have attempted this but havent found it successful- still returning a 401.


Or are you suggesting that we rewrite the query to use GET parameters, and set the header to application/atom+xml ?


Thanks for you help with this so far.


So there definitely seems to be confusion on here and I apologize.  The request type (POST, GET, PUT, DELETE) is unrelated to the OAuth issue, as the request type is indicitive of the action you're looking to do with our API and will change based on that. 


The OAuth issue is being caused because you are sending the OAuth authentication data as POST or GET parameters instead of as header values.  Instead of sending them as parameters at all, you would need to send them as additional header values.  This would be in addition to the header for Content-Type, making an array of header values to send (which is likely going to be an array of 7 items if you include the Content-Type header). 

Dave Berard
Senior Product Manager, Constant Contact
Regular Participant

This morning I check every things again , and now it work , thank so much for fixing bug in OAuth 1.0.  

So I don't need to fix any code on our site , it work like it used to be.


Regular Participant

Hi I think it is working now-


Its likely that your update yesterday fixed this. 


Thanks for your help

Great!  If you run into any other issues please feel free to post your questions here on the forum!



Benjamin Soder
NOC Analyst
Constant Contact
Developer Portal

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

Visit Page