About JasonP026

JasonP026 · ‎03-07-2023

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?

JasonP026 · ‎03-04-2023

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?

JasonP026 · ‎10-05-2019

We have our own templates and we use tags like <font face="Arial"> to support various mail readers. This is valid HTML and it is crucial to our formatting. We don't put CSS in our emails for good reason. The fact that your new code editor is stripping valid HTML tags is completely ridiculous and unacceptable. It is unusable for our purposes. For this month's mailing we were able to still using the old version. If your new editor won't give us free reign to use basic HTML tags, we respectfully need to know what your deprecation schedule for the old version looks like. At what point is it going to disappear completely? Sadly, the only way we can stay with your company is if you keep the old code editor available indefinitely. Regards, Josh Strike CTO at the Barker Lounge

Re: v2 contact endpoint - roadmap?

v2 contact endpoint - roadmap?

New custom code editor strips valid HTML