Hello,   Our PHP Wrapper Library includes an example verification flow (example_verfication.php in the root folder of the library), and an additional standalone example can be found in the Authentication page of the Wiki for the PHP library. The Datastore class implemented in these authentication flow stores the necessary credentials in the $_SESSION array, so it's useful as long as the user's connection with our server is maintained.   Because the $_SESSION array is lost if the session isn't maintained, if you need to eliminate the need to re-authorize with each new session, we encourage you add the necessary functions to your local copy of the Datastore class, or you may include your own class to pull the authentication data from the $_SESSION after users authorize, and set a cookie in the client browser, or store it securely in a SQL database table, for example.    The specifics of how you do this depend on the nature of your application. An application hosted on your own server but used by many may work best using a client flow for oAuth 2 and cookies on the client side , while installation of your application on each user's webhost would probably work best with server/web application flow oAuth 2 (implemented in the oAuth 2 examples mentioend above), and server-side storage of the access token. For technical details of our oAuth 2 server and client flow implementation, see our oAuth 2 Authentication Documentation.   I hope this information is helpful to you.  Let us know if you have additional questions. ... View more

Hello,   Can you PM me the email address your email replies were going to? To sent a  personal message - click on my forum name, and find the link to send me a message in my profile.   Based on the error message, it appears your reuqest may not be formed correctly by your application. In OAuth 2, if you have already authenticated and obtained an Access token and stored it on your side, you would only provide the access token either in the header or as a parameter on the request URL for your API call.   Make sure your script is set to format requests for OAuth 2, rather than basic or OAuth 1.0a.  If you're using the wrapper library, this is accomplished where you instantiated the ConstantContact object.   If you can post some of your code here with any unique identifyers (account credentials) removed, or simply send them as a text file attachment to webservices@constantcontact.com, we can take a look and try to offer more specific advice.   ... View more

Great ideas, and I know the Katz Contact Form 7/Constant Contact integration works very well.   ... View more

Hello,   Thank you for your feedback. We appreciate feedback like this, as we're always seeking ways to make our API better and more accessible for developers.  Currently, contacts are unique  in our system at the account level (See this explanation of our contact data model, which may differ from some other services currently). If you're adding a contact to a list that has never previously been added to an account, this can be done with a single post requests, assumign you have the list ID's for the lists you wish to add them to.  Since this is actually "creating" a contact in the account, it's actually a create contact call.     The call to add a contact to a list is effectively updating the list attribute of the contact. Because the normal PUT request to update the contact will replace current details with new ones provided in your PUT request, we suggest a GET for the contact details first, then adding the list among the existing ones in the contact XML/object, and submitted that updated XML/object with a PUT request - which I think is what you're referring to. If you're updating or syncing a large number of contacts, using a bulk activity to do the update (as in syncing or updating and entire list of contacts at once), the action appends the details for each contact, instead.   Thanks again for the feedback. ... View more

I don't know what type of intergration you are working on, but eventually we'll be moving entirely to OAuth 2.0.  For some integrations this requires you to go through the process once to get an access token, then store that access token, or hard-code it into your applications scripts, so each use doesn't require someone to re-authorize. If you let us know the nature of the integration (feel free to email if you want), we can probably provide a flow and perhaps some suggestions on good ways to implement an authentication strategy.   Cheers, ... View more

Hello,   The first call is actually a redirect to the authorize url (your $codeurl).  This should be a redirect of the browser (as if a link to the url were clicked). the browser's next stop would be a login page where the user must enter the username and password, then if valid they will be asked to allow access - granting permission for your application to access their account resources. Our server then should redirect to your redirect uri, where you callback script makes a cURL request to exchange the authorization coede provided in that callback for the access token that serves as the authentication credential in your subsequent API requests.   I checked you API Key (I found two), and I assume you are using the one in your script that has a redirect URI in it's settings, as one doesn't have a redirect URI.   You can email us directly at webservices@constantcontact.com, and we'll be happy to offer whatever additional assistance we can. ... View more

Hello,   I will follow-up with Dave and he or I will update this topic in response on your question about whether searching for lists by name is forthcoming to Dave, but t he current version of the PHP Library should return a list object when a new list is successfully created using the addList function, and this object should include the ID and name for the list that was created, so you could store the name and associated ID locally. Having done that, it would be possible to query your own database to get the list details needed to make calls on a specific list.   Cheers, ... View more

Hello,   There are limitations that have to be worked around to accomplish specialized tasks with any web-based platform. As our system doesn't maintain a record of previous list memberships, the only way to do this is some variation of what Shannon described, really.  Depending on how you need to process the data, if you keep contact records stored locally, as well as in your Constant Contact account, and you sync frequently using bulk activities to keep list associations for contacts up-to-date on your side, then do separate syncs of those on your do-not-mail list with your local system, but in that sync don't touch the list memberships - syncing only to mark the contact locally as unusubscribed, you will always have the last list membership associations for you opt-out contacts.     Sure, it may require some development to code your sync integration to handle this, but once done, using bulk activities for the syncs and leaving the hard work up to your application should work. Others sync a variety of contact data in our systems with that in their local databases using approaches like this, so it's definitely workable if the development is feasible for you. ... View more

Thank you for the feedback.  I see the problem for your application given our current event API functionality. Our Events API is one of the newer additions to our API services, and additional updates to it's capabilities may be added in future updates. Our developers pay attention to feature requests we submit on customer behalf and which are posted on this forum. ... View more

Our accounts are intended to service one brand/location per account, as you are aware, but the short answer to your question is that you can work around this by controlling access to different functions of your integration on your end. Because all of the calls to the functions to create campaigns is handled in your application/integration, if you control access to these functions for your users at your integration, and store your authentication credentials on your side, for use in making the actual calls, there is no reason you couldn't effectively work around the single user/brand account limitation. It would just require the appropriate development on your part to implement access controls for your users. ... View more

Hello,   Are you including any HTML tags/code in your description? If so, these aren't allowed within the description element, and our system would have no way to distinquish them from the XML tags, so would likely error when it came across a tag that was not valid for the XML.   Can you capture your XML, and post it here (after removing any account credentials or unique identifyers you don't want to share), or email it with a  link to this topic to webservices@constantcontact.com? We'd be happy to take a look at it and do some trial and error troubleshooting to see if we can help you find the source of the problem. ... View more

Hello,   Are you creating your emails via the API, or within a Constant Contact account?  If you are creating your emails through the website using our graphical web-based editor, we have an FAQ that describes how to add dynamic links to emails.   Essentially, you already have the contact name, so you would need to add Contact ID in a custom field in each contact's details, and then you can merge the details you want to use into your email along with other portions of the HTML code that will create the hyperlink.     This can also be done when creating custom-coded emails (XHTML only), through our Advanced Editor in the User Interface, or through the Campaigns API.   If you have questions regarding use of the API to create your emails, I'll be happy to help, but you can get direct assistance from our Customer Support staff on how to create dynamic links (for custom emails, our second-level technical support team can call you and provide a demonstration of this in your account).   Cheers, ... View more

There are functions in our wrapper library classes that convert your contact object to the formatted XML and submit that as the body of the requests made to our API.  the makeRequest function in the CTCTRequest class (Authentication.php file of the wrapper library), is the function that makes the HTTP request via cURL to our API, so you can add code to this function to capture the contents of the $body variable, which should include the formatted XML that is being submitted with your request.   I hope this helps. One you have the XML, we can offer some additional advice or assistance in troubleshooting, if needed.   The first step I would take from your side is to use that XML to create a manual API request using RESTClient. This helpful utility allows you to set up and manually make HTTP requests to REST API services like ours, and it will provide the HTTP status response, and any error message contained in the response body. Wrapper libraries may not pass the response body along to you, and it often contains a more precise message that identified the source of 400 errors. ... View more

Hello Dan,   The redirect_uri doesn't have to be SSL (HTTPS).  If you are using server flow, you can use whatever redirect URI you want, but you must have hosted there some script or application that can obtain the authorization code that will be sent there when browser is redirected to the redirect uri after you login and grant access (authorize), and then the script or application must be able to make a second request to our systems to exchange the authorization code for the access token. Capture the response and if your request was made properly, it will include the JSON containing the access token you need to store and use for additional API requests.   You can have a redirect uri that gets the authorization code, then provides it to an outside server, which can then make a cURL request to get the token, as well. After authorizing and granting access, our system will always redirect to your redirect uri, however, and this must match the one provided  in your API Key settings.   I hope that helps. ... View more

For those arriving at this topic in search of an example on creating campaigns via our PHP Wrapper Library, I've added an example to the examples folder in our PHP Wrapper Library that consists of a simple form for creating an email campaign. ... View more

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. ... View more

Hello,   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.   Cheers, ... View more

In our system, contacts are associated with the 'account' they are added to rather than a spcific list belonging to an account. List membership is specified as an attribute of associated with the contact, rather than vice versa.  Strictly speaking, Do Not Mail, Removed, and Active are not lists attributes, but are "Status" attributes of a contact. If a contact opts out, they go on the Do Not Mail list, so we can enforce the contact's wishes on whether to recieve or not recieve your mailings. By convention, we use a DELETE method HTTP request to our API to "Unsubscribe" contacts. Simply "Removing" contacts from your active list, while retaining the ability to add them to lists again at some point in the future for the purpose of managing contacts and lists, is done instead by updating the contact and simply including no lists in the contact object.  These statuses are not directly set by editing them in the contact object. Our system assigns the status. Active status is assigned when a contacts is added to an active maling list in an account.   I don't understand your second question. Unsubscribing is a request by the contact that you no longer email them, and our system is designed to enforce that request until the contact initiates an active relationship with you. If you want to have a different option to allow people to remove themselves from your regular mailings, but remain available for you to send only occassional emails to, then you should have a separate "active" list in your account for only those who want occassional emails, but don't want the regular (frequenty or infrequent) emails, or you should update the contact to remove them from all active lists, but don't delete them.   Make sure if you do this, however, that you are clear on your form that the contact will not recieve the regular emails, but may be occassionally contacted for other purposes, so it is not confused with a complete unusubscribe from all your mailings. If there is confusion, this may cause SPAM complaints. ... View more

  In general, your flow appears reasonable, but your method for creating a contact object to use to update list membership attributes of a given contact won't work, because when you create a new contact object, the object will not contain the contact id url.  Because to udpate a contact, you must include not  only the email address, but the contact id in the contact object, and you will need to make sure all the requires elements are indcluded in your request, the recommended flow goes like this:   1) Check if contact exists using $ConstantContact-> searchContactsByEmail($email) 2) If exists, get details for the contact using getContactDetails($Contact) using the limited contact object returned in step 1 to request full detials for the contact, which will include all required elements for the update request. 3) Modfy the lists in the contact object and submit your update request using updateContact($Contact)   I hope this helps you out. If you modify your code and run into difficulties with it on execution, please add breakpoints to your code to identify where the issue occurs, if you don't get an informative error message, and echo or var_dump any variables bieng used at that point in the code. If a status code is echoed to browser that indicates the API request was unsuccessful for some reason other than authentication problems,  you can also add some code to the makeRequest function in Authentication.php to dump the XML being submitted. Comparing the XML to our API requirements specified in the Constant Contact API Documentation for Contacts (see Contacts Collection and Resource documentation and Updating Contact Information, in particular).   Cheers, ... View more

Hello Matthew,   Our Customer Support staff that handle phone support are skilled for helping customers use our User Interface/website (the UI), but support of the Application Programming Interface (API) that applications use to access account functions is a far more technical topic, so your request has been moved to our Developer Support Forum.   Our API allows access to contact and list management functions, and campaign creation and scheduling (with permission) functions though HTTP Requests to our API servers, and these can be done through a PHP application.   The short answer to your question is "yes," but with the caveat that the programming to control frequency of emails, and any list/contact management actions requires to vary frequencies of individual or groups of contacts, from your Constant Contact musts all be accomplished through your app/integration's programming.   Links to a variety of code samples, including a PHP Wrapper Library, which handles the most difficult parts of programming HTTP requests to our API, making it easier for developers to integrate, can be found on http://developer.constantcontact.com, along with our API Documentation, which provides technical requirements for requests to our API. ... View more

We made some modifications to the OAuth login page in late July that eliminated eliminated the option to create a new Constant Contact account from our forgot password page, and have also now removed the Yahoo! login option, so I believe our OAuth login page should no longer cause App Store rejection.   Cheers, ... View more

Hello,   To display in the User Interface as added by "Contact", you should set the OptInSource to "ACTION_BY_CONTACT."   This not only changes the added-by fields, but also controls whether contacts will recieve an account welcome email when they are added to the list via your checkout/signup process. They should also be made aware during checkout, if possible that they will be receiving emails from you, and have the option not to be added at that time, if possible. That helps ensure that you won't inadvertently send someone emails they may not realize they'll be recieving.   I hope this helps. Let us know if you have additional questions. ... View more

Hello Dean,   As you're talking about an integration using our API, we've moved your post to our developer support forum. A 409 repsonse from our API servers indicates that the email address you are attempting to add to the list has previously been added to the Constant Contact account. In our current data model, contacts are unique at the account level, and lists are attributes of the contact, rather than vice versa. Removing contacts doesn't remove the contact-account association, it merely changes their status. In order to add contacts who already exists in an account (even if removed or unsubscribed), based on HTTP standards, our API requires a different type of HTTP request than is used to create a new contact in an account.   To create new contacts, POST method requests are used, while PUT method requests must be used to update details (including list membership attributes).    Typically, if you need a form that both creates new contacts in your account, and updates existing contacts, you would have one that   1) Checks to see if the contact exists (GET request to search for contact by email address). 2) If contact exists, you get the contact's full details (GET request on contact ID).   3) Update the contents of the contact's details, add in any new lists you want the contact to be on, without removing previous lists, and the update the contact (PUT request to update).   4) If in step 1, the contact is not found in the account, you simply create it (POST request).   There is a data security risk to allowing publicly accessible forms to be used to update contacts, in that anyone with one of your contact's email addresses could enter it in the form, and change any other details you include in your form. I could use your email address and change your name to "Fred Flintstone" (or something worse), and also subscribe you to recieve additional mailings potentially (potential SPAM complaints could result).   Let us know if you have additional questions. If you're using our PHP wrapper, or the CCSFG, there may be a some additional information or assistance we can provide you. ... View more

Hello OAuth 2 will redirect you to Authorize through our Oauth login page, and then after authorizing, will redirect back to your redirect URI (your callback script url), passing a code parameter appended to the redirect URI. On your end, another call must then be made from your callback script to exchange this code for an authorization token. Once obtained, if you're using the wrapper's datastore class to save the credentials, by default this simply stores the access token in the $_SESSION array, so if you then redirect or link to a script that doesn't include a session_start() function to maintain the current session. the authentication credentials will be lost before any of your script's calls are made.   We have left secure server/side or local storage of the authorization credentials up to the developer with the wrapper, as there are many options for this.    If the above don't help you get things working, feel free to email webservices@constantcontact.com, and one of our API Support team may be able to more directly assist you in getting your code to fly. ... View more

Hello,   The 403 response isn't what I would expect if you are trying to create a contact in an account in which it already exists (which uses a POST request), instead of updating the contact to add the desired list/interest attribute (which uses a PUT request).   Our API servers will return a 409 if you attenmpt to use a POST request using an email address that is already associated with the account (one that has been previously added, even if it is removed). Removed and Do-Not-Mail are not list/interest attributes in our system, but instead are a "status" of a contact. Our system doesn't delete contact-account associations when people unsubscribe, because to comply with U.S. federal anti-spam law (The CAN-SPAM Act), unsubscribing is not just asking to be taken off a list, but is a specific request that you not send the contact additional emails.   The best approach to adding contacts, if you want people to be able to resubscribe using your form, is not to try and use an addSubscriber() function that simply tries to do a POST method request, but instead to do the following:   1) Search for Contact by email address (this does a GET request to get the contact ID for a given email address).   2) If the request in #1 is successful, you then get the contact details (GET request on the contact's ID).   3) Update the details returned from #2 with new data (add contact lists to the contact's details) and then submit an update contact request. For contacts that have unsubscribed, this must be done as an action initiated by the contact, and will result in an Update Profile email being sent to their email address, which they must click a link in, and confirm their interest in recieving your emails on a webform that we host (can edit within the Constant Contact account UI). After they do this, they will be added to the selected list - this is done as a means of confirming that the person making the request to resubscribe is a person in control of the email address being re-subscribed, and that this is not being done with the email address owners knowledge.   4) If the request made in #1 finds no contact, you do an add contact, or addSubscriber type of request (a POST method request) to create the contact.   For step 3, if you wanted to warn someone that they are going to recieve an update profile email and they will need to follow the instructions there to complete resubscription, you would need to check the status in the contact'd details to see if it is "Do Not Mail" and if so, display the appropriate message after they submitted their resubscribe request, and also you would want to make sure that for just that one request, if it is not already done for all your reuqests, that the optInSource in the contact details submitted with the update is set to "ACTION_BY_CONTACT" (request to resubscribe without this for Do Not Mail status contacts will fail.   How you set all of the above up depends on whether you're using one of our wrapper libraries, or sample code packages, some of which do not currently have our most updated wrapper libraries integrated yet.   I hope the above is helpful to you. Let us know if you have more questions. If you need more assistance with the above, you can email webservices@constantcontact.com, and one of our API Support Team may be able to offer a little more directed help.     ... View more

Hello,   The form input code you've included appears to be from a signup form that works through our API, and forms set up using signup form integrations that work through our API would require that the integration be programmed to exclude lists when they are set not to display on your JMML form. Setting this field using the checkbox in your account will only automatically affect whether it appears on the JMML form you can edit through the website/user interface, which is hosted on our systems.   Integrations that work through out API will recieve all lists when they use the getlists function to obtain the account lists, regardless of your selection in the user interface, it's just that those that are selected through the UI to appear on the form will have a value of "Yes" if in the DisplayOnSignup element in the XML our API returns, and "No" if the JMML box is not selected on the website UI. Since the integration you're using probably isn't checking to see what this value is and using it to determine which lists are displayed, it is likely just displaying them all.    I sent you a PM to request some additional information I can use to try an offer you some additional advice/assitance. ... View more

Hi Mark,   When you say the lists don't updated, are you referring to your form itself, or the lists visible in the CCSFG setup? The CCSFG, once you navigate to the setup script and enter your credentials, should allow you to go through setup again, and pick new lists.  Once you've done that, you have to proceed through the remaining steps and new code is generated for your form that includes the code your new lists.     You can email us at webservices@constantcontact.com if you need more assistance and one of our API Support Team can offer additional assistance. ... View more