How are we supposed to accomplish the following without migrating to one of your competitors? GOAL: Reliably send data into properly named custom fields every time the form on our landing page is filled out without having to Token re-authenticate every time we send data.   We cant as far as I know, unless we take our business elsewhere. I can accomplish the goal stated above in 15 seconds with 1 simple class and a copy/paste of 1 key and 1 secret on other email systems. This is why I move people away from Constant Contact and every time I have to mess with this system it gets worse.   V1 was useless, V2 showed promise but was poorly planned, and V3 is equally useless.   I am going to state my conclusion/theory first: I suspect the REAL reason Constant Contact has implemented this "very peculiar Oauth setup" is because the company infrastructure can not handle live API call demands. Ergo: this overly elaborate system is a mask for a failing company falling apart at the seams that can not support it's customer base and needs. So, the only way to hide that is to slow down and in some cases prevent people from using the system,   Here is how I arrived at that conclusion: First, consider that I know very well all I need is a Key and a Secret to send data into an API, hard-coded into my server side application. Using these tokens via Oauth is not necessary, and in this case, absurd. I am sending data back and forth between SalesForce, MySQL, MS SQL company server, Twilio, Mailchimp, ect... none of them have this problem.    Consider the following set of Catch 22 limitations preventing us from using constantcontact in any reasonable and sane way.   We have a Landing page we advertise using Google, Facebook and MS Ads. People visit that page at all different times of the day randomly. We have a complex lead generation system that collects POST data and sends it to - Sales force - Local/regional office DB's - Specific sales people based on certain criteria - Twillio text message - and of course 'the newsletter' which at this time is 'constantcontact' (but not for long)   PROBLEMS: V2 of the API does not allow sane custom field names, we can only name things "CustomField1" and "CustomField2" We need to name things like this "Sign up source", "Referral URL", "Coupon code", "Lead gen type", "Interest" V2 of the API does not allow that (but v2 does have an auth token that lasts for a long time)   The new 'V3' of the API supposedly allows us to send sane custom field names But, V3 makes us get a new refreshToken every 2 hours which is worthless, unreliable and problematic (at best) Furthermore, when we do manage to get a new Token it comes with another refreshToken which makes the previous refreshToken worthless   Ultimately this means there is a 50% failure rate on our lead gen forms when someone checks the box that says "add to mail list" because if 2 people are using that page at the same time, or, if more than 2 hours occurs the refreshToken process has to be started all over again.   Why would you set it up this way? I think this is the worst way possible to set up this kind of system. Unless... you cant handle the volume of customers who are sending data into your system. In which case, see my conclusion, above.     The whole point of using an API like this from a dev standpoint is to send over the Key and Secret and then be allowed to send data into the system. The way you have set up the refresh tokens makes this overly elaborate and ultimately UNSTABLE AND UNRELIABLE.  ... View more

I have been doing this for a long time, and the SDK and API here needs a serious overhaul.   Candidly, it's 2020 and I see no good reason to have 478 files across 137 folders using dependencies like Guzzle and React for a simple PHP integration.   I just spent 6 hours on what should have been a 15 min integration and could have been a 5min copy/paste operation. It would have taken less time to migrate to a competitor. Clients do not want to pay for that, this is an impediment to constantcontact's future.   I should be able to drop my API key and Secret into a variable then implement 1 class to send/retrieve data and get the job done.   I want to point out that this 478 file 137 folder dinosaur: https://github.com/constantcontact/php-sdk       Because this http://constantcontact.github.io/php-sdk/ is some of the worst documentation I have seen since 2001.  Mambo and then Joomla had better documentation...   Constructive part: Sit down and watch some PHP developers try to use your system to add emails and custom data to a specific list using a simple POST action server side. A simple task, say nothing, watch them try to use your SDK and documentation to get something done.   Take notes, give them no verbal direction simply say to them "ok, make a form that adds emails to this list. go" and kick back and watch and listen as they throw things and swear at the screen. Count the number of times "WTFITS?" is said out loud.    At the end, ask them what needs to be improved and if this post here is "true" or not.   *edited by moderator to keep in line with Community guidelines https://community.constantcontact.com/t5/custom/page/page-id/CommunityGuidelines ... View more