Can not make sensible use of V3 API - refreshToken's make system useless

[ChristianZ825]

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. 

[Jimmy_D]

Hi @ChristianZ825,

I can understand your frustrations when a company implements new changes, but I assure you they are for good reasons. We changed our Access Tokens to expire sooner to help ensure higher security. While not everyone appreciates the extra security we have notice a decrease in bad actors compromising accounts.

When using the v3 API your Access Token can expire anywhere between two hours and 24 hours depending on use. When you generate the Access Token you also generate a Refresh Token; the idea is that you store both of these tokens. You use the Access Token to make your API calls and when it does finally expire you then use the Refresh Token to generate a new set of Access/Refresh Tokens and this is Step 5 in the oAuth flow. As long as you do not go through the other steps your Refresh Token will never expire of be invalidated.

[user942713]

Hey Jimmy,

I have similar problems in my system, but I understand that CC is changing the refresh token each time due to a secuirity measure. But I have a question here, let's say there are multiple places in app where CC integration is required with the same account. If my users authenticate for multiple places, only one of them would work because only 1 pair of access/refresh tokens will be valid. I can still work around this problem by storing one pair of access/refresh token in one place, and using that in all places in app. BUT, tell me this, let's say 9 o clock, the acess token is going to expire. And 9:01, 3-4 places in my code pick up the refresh token to generate new access token, and then make some API call to push data in CC. Some of those requests will fail, right? Because one of them will generate a new refresh token and if the other requests are running parellel, they will pick up the old refresh token from the db in that few 100 ms, and they would fail, rigth?