v2 contact endpoint - roadmap?

[JasonP026]

Hi. I run the website for a fairly small company w/ about 35k contacts, split into about a dozen different lists (by physical location of the store the customer signs up at). They send all their newsletters manually. They have a web registration form for signing up new customers to their business. Within that form, there's a checkbox to opt in for newsletters. The website form onboards the customer, and if that box is checked, it makes a simple call through the v2 API (using the PHP SDK) to add the customer's email address to the list for the store they're signing up at. It's very, very simple. We don't store the customer's constant contact ID, but we do store the v2-style list ID for each store (integer). We have a single API key and access token.

Are there any plans to build out a v3 PHP SDK? And/or what is the timeline on deprecation of the v2 contact endpoint? The company doesn't feel it's worth it to build and maintain their own miniature ConstantContact SDK to deal with OAuth tokens and all that just to simply add email addresses to one of a few static lists. It's not even clear that we would be able to do this in v3 in a simple way as the OAuth documentation is confusing and seems to imply the need for clients to login; and rewriting around this is unfortunately very low on the priority list for their own upgrade strategy.

Will you continue to provide a simple endpoint where we can add email addresses to existing lists using just an API key?

[Courtney_E]

Hello JasonP026,

Thank you for reaching out to Constant Contact API Developer Support. My team is here to assist outside software developers with questions about building into Constant Contact's API.

While no date is currently set, there will be a point in the near future where our legacy V2 API will begin deprecation, as the deprecation process for our retired V1 API is nearly complete. Due to this, while we will continue to deploy critical bug fixes at this time, we will not be doing any more development for V2 or its endpoints, and strongly recommend upgrading to the V3 API to ensure you're ahead of the curve. Currently, we've already retired the V2 endpoint for Custom Code email creation, as it used an outdated version of our Custom Code editor that has been retired. Any future deprecation-related notices for V2 communications will likely be sent specifically to whichever email address was registered in the Mashery Developer portal  (https://constantcontact.mashery.com/) for the legacy V2 API key that the integration uses to connect. 

The request for V3 application code samples is currently under review. However, we're currently still adding endpoints and capabilities to the V3 API, and do not plan to publish official sample apps until that process is complete. Your feedback and experience with this request is essential to improving our product, so thank you for reaching out to us regarding this matter.

In the meantime, here are the example calls that are currently available for V3:

V3 Code Samples:

https://v3.developer.constantcontact.com/api_guide/tag_code_samples.html

Additionally, you can utilize our API Reference tester to test out the functionality of our available endpoints to see how they will work once programmed within your application:

https://v3.developer.constantcontact.com/api_reference/index.html

However, in case you find it helpful:

For additional reference, here is the link to a sample that was created/shared on our Developer Forum by a 3rd party developer (NOT created or supported by Constant Contact) for V3 using PHP:

https://community.constantcontact.com/t5/Developer-Support-ask-questions/PHP-V3-Library-now-updated-...

Please have a look and let us know if you have any other questions!

[JasonP026]

Hello,

Just looking through the API notes and that PHP library... the authorization steps don't make sense to me. We don't want to expose any Constant Contact functionality to our website users. Our users are signing up for our service and we are simply trying to add them to a mailing list at the same time (with their consent). Therefore we don't want to have them have to login to Constant Contact. We should not need to have a user re-authorize our app, which wouldn't make any sense. I don't understand what the use case is for the API to require end user authorization unless we were writing our own front-end for Constant Contact, which we're not.

We simply want a basic endpoint with a permanent API key to add users to existing lists. Upgrading to PHP 8 and maintaining and refreshing OAuth tokens and re-logging the app in is really beyond the scope. An end user should not need to be sessioned to do this.

For example, the MailChimp API will let us store a key and just add email addresses to an "audience" (list) through a simple cUrl call with that key. So does the CC v2 API.

This has reignited questions of migrating to a different service. Does Constant Contact plan to continue providing a simple endpoint for adding to lists, for companies like ours?

[John__B]

Hello JasonP026,

Thank you for reaching out to Constant Contact API Developer Support. My team is here to assist outside software developers with questions about building into Constant Contact's API.

An app developed using our API can be used by any Constant Contact account holder, if the developer chooses to share their app. In our documentation, when the term "user" is used in the OAuth description, this is referring to the Constant Contact account holder who is authorizing the app to access their Constant Contact account.

In the example you provided of the sign-up form on your company’s website, you would be both the developer and the user of the application. Your website visitors who are signing up through your form wouldn’t directly be “users” of the app, they would simply be providing the data (by filling out the form), which the app would then send to Constant Contact. 

Our V2 API does also require the use of OAuth, and using an access token to authorize requests. The difference between the API versions has to do with token lifetime. Our V2 API grants tokens with a 10 year lifetime and does not include the ability to refresh these tokens when they expire. In keeping with evolving security practices, our V3 API grants access tokens with a shorter lifetime, which can be refreshed. I hope this helps to clarify some of your concerns. 

Please let us know if you have any other questions!

Regards,