Cannot retrieve access_token -- no errors, just blank result

[KathleenH522]

Hi,

First time trying to connect, so hopefully this isn't dumb.

1. Using V3 API
2. Have created an account
3. Have created an application
4. Have created an API Key / Client ID
5. Have created a secret
6. Have created a formatted URL, which successfully produces an authorization code after I login and allow it
7. I plug these values into the getAccessToken() function from https://v3.developer.constantcontact.com/api_guide/server_flow.html:
   • RedirectURI matches exactly what's in the application portal
   • ClientID matches exactly what's in the application portal
   • ClientSecret matches exactly what's in the application portal
   • Code matches exactly the authorization code returned in step 6 above
   • I'm doing all this within 60 seconds of generating the authorization code
8. I'm expected to be given an access_token and refresh_token
9. Result:  blank.  I echo the result and there's nothing there.

Feels like I must be doing something obviously wrong, but can't figure out what?

Thanks in advance for any guidance.

Steve

[KathleenH522]

I should add to the notes above:  I believe (could be wrong) that because I'm using V3, I am not able to use the Mashery interface as an alternative way to generate an access token.  True?  I believe that because when I try to log into Mashery using the same credentials that I use to log into the V3 sites, those credentials aren't recognized, so I'm assuming that everything else (application name, API key, secret) are all specific to V3 integration, and therefore the only way to get an access token is through a POST and some kind of response (and I'm getting none; not even an error).

Thanks in advance for any suggestions.

[Jimmy_D]

Hello @KathleenH522,

Thank you for reaching out to Constant Contact's API Support.

The two versions of our API are not cross compatible so you are correct that you cannot use Mashery to get a v3 Access Token.

Make sure when you use the redirect URI in your oAuth call that it needs to be encoded. This means that if your redirect URI is https://localhost it should look like https%3A%2F%2Flocalhost in your API POST call. Here is a full breakdown of what it would look like when using POSTman.

step 1 - auth request URL

https://api.cc.email/v3/idfed?client_id={api_key}&redirect_uri={encoded redirect_uri}&response_type=code&scope=contact_data+campaign_data+account_read+account_update

step 2 - use request URL

put above URL in your browser, login with CTCT username/password, click Allow

step 3 - authorization code

grab authorization code from browser URL

step 4 - exchange code for tokens

(header) Authorization Basic api_key:client_secret (base64 encoded)

https://idfed.constantcontact.com/as/token.oauth2?code=(authorization_code)&redirect_uri={encoded redirect_uri}&grant_type=authorization_code

step 5 - refresh token

(header) Authorization Basic api_key:client_secret (base64 encoded)

https://idfed.constantcontact.com/as/token.oauth2?refresh_token={refresh_token}&grant_type=refresh_t...

[SteveA3416]

I am having a similar strange problem.

My setup and redirects are all proper.

What youre referring to as

step 4 - exchange code for tokens

(header) Authorization Basic api_key:client_secret (base64 encoded)

https://idfed.constantcontact.com/as/token.oauth2?code=(authorization_code)&redirect_uri={encoded redirect_uri}&grant_type=authorization_code

-----------------------------

This is what Im getting back from the server. There is a # symbol instead of the query string ? that is supposed to be there which is preventing me from getting the code from the URI without parsing it which I shouldnt have to.

https://mydomain.com/constant3.php#access_token=SNLrLESU8j15QKeQKVWgR0j3wway&token_type=Bearer

[Jimmy_D]

Hi @SteveA3416,

The URL you have listed doesn't make sense to me. If that is your redirect URI then you should not have the other parameters in it such as access_token and token_type (unless those are part of your own website, but that does not seem to be the case).

Or that is the URL that is returned to you in Step 4 which also does not make sense as the URL that will make the return will also be from idfed.constantcontact.com.

I'm happy to troubleshoot this; however some of the information might need to be kept secret for security reasons. You can reach out to use at webservices(at)constantcontact(dot)com.