There seems to be some misconception about who the oAuth process is used for and the steps that are needed. The steps you have laid out are incorrect. Let me see if I can clarify how everything should be set up.
Your application is going to be a sign-up form that will be placed on your website. The oAuth process will be used for the account that receives data from the sign-up
form. This means the oAuth flow needs to be done only for the single Constant Contact account that gets connected to that sign-up form. The potentially 1000's of people who fill out your sign-up form do not need to go through the oAuth flow.
You listed 10 potential steps in the oAuth process when there are actually only 5 and out of those 5 steps only 1 of them ever needs to be repeated.
Step 1 of our oAuth documentation is used to put together the URL that will eventually generate your Authorization code.
Step 2 doesn't actually have any code on our side. This step is done completely on the developer's side. This is where you take the URL from Step 1 and add it to your application in a way that will direct the user of the sign-up form (remember this will be the Constant Contact account owner, not the people who fill out the form) to a website. They will enter their Constant Contact username/password and click on the Allow button which will give permission to your application to send/receive data to/from their account.
Step 3 is where the redirect URI that you set when creating your API Key is used. After the Allow button is clicked in the previous step the user will be directed to your redirect URI. In the address bar of the browser will be your redirect URI along with the Authorization code appended to the end. This is where you need to your application grab that code to be used in the next step.
Step 4 is where you take the Authorization code from the previous step and make a POST call to our API. You will exchange the Authorization code for an Access Token and a Refresh Token. You will want to store both of these tokens for later use. You no longer need to store the Authorization code.
The above 4 steps only need to occur once for each user of your sign-up form application.
Step 5 is the only step that ever needs to be repeated assuming all of the previous steps were done without errors. Once the Access Token expires you will use the Refresh token to make a POST call to our API. This will generate a new Access Token and Refresh Token. You will then want to replace the old Access/Refresh Tokens with the new tokens. Since the Access Token has a maximum life span of 24 hours you will be repeating this step at least once every 24 hours per user. Again please keep in mind the user of your application is the owner of the Constant Contact account that receives the data from the sign-up form and not the people that fill out the sign-up form.
I understand the process clearly.
Pleas allow me to convince you this problem is real, and a good solution is not available to us:
Try to build a simple LANDING PAGE in standalone PHP that hooks up to Google Ads.
3 custom fields for Constant Contact needed: "Project type, Budget, State"
Add a checkbox that says "subscribe to our mailing list"
No database. no CMS. nothing fancy.
Just a PHP form and a landing page.
Then, watch someone try to build it and connect it to V3 of the API
Record that process. Try it your self. Have another developer try it.
Don't show them how to do it. Let them try to make sense of the documentation.
I think you will see the areas of improvement needed,
and, why it is impossible to pull this off easily, efficiently and fast.
By witnessing other people use this system things will quickly become apparent:
1- improvements to the documentation layer
2- why step 5 is unnecessary (and overly elaborate)
The main challenge we face here is the "renewal" of the token.
YAGNI applies here - a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary.
Step 5 is not necessary.
To do that we have to involve abstract elements of time, error checking, return error codes, saving the token, saving the time it was created, recreating it, CRON jobs, a database or writing to the file-system. This turns a 3 hour bang up job into weeks of development, writing classes, debugging and even then, the possibility exists that leads can be lost if something go's wrong.
It's unnecessary for just trying to make a landing page to collect emails don't you think?
We really need a more elegant solution.
Can you look at this problem and do something effective for us?
The simple answer is the right one here I think: let us generate and sign a token that does not expire to use our own CC list.
I urge you to please try to build a simple PHP/HTML landing page that uses the V3 API yourself and watch someone else build one.
The experience will reveal very important improvements that are desperately needed to make V3 a practical and useful utility.
View API documentation, code samples, get your API key.Visit Page