v2 or v3 API for very basic integration?

[ChrisB73]

I recently set up PHP contact form on a website (for a friend/freelance client) that used the CtCt v2 API to handle a newsletter-opt-in checkbox in the form. All was working fine, until this client migrated his site to a new host running PHP 7.1.25 (was previous 5.x, I suppose). There was some issue with the guzzle dependency in the provided CtCt PHP SDK, and I found a post in this form where a developer pretty clearly stated that on PHP 7+, you really should be using the new v3 API.

Now that I've spend some looking at the v3 docs, though, I'm confused about Oauth. Both the client and server flows explained in the docs seem to assume a CC customer manually end user providing authentication as part of the process — but this is a very basic integration where the code living on the CC customer's own web server needs to access that owner's list data and create a contact in response to someone else's submission of a form—the site owner is not present in the transaction to authenticate themselves. Is this a case the v3 API can handle?

Most likely scenario is I'm just looking at this wrong and need some explanation, I realize...

[ChrisB73]

The post I referred to was https://community.constantcontact.com/t5/Developer-Support-ask-questions/PHP-5-4-v-7-2/m-p/307766... and I noticed at the end it does say that the alpha version of the SDK did seem to work for the person who posted, so I guess I'll try that even though the thread is a bit over a year old. I'd still love to hear back on this just to help me understand Oauth better.

[Jimmy_D · Accepted solution]

Hi @ChrisB73,

Thanks for reaching out to Constant Contact's API Support.

The v2 API also required the user's input to authorize. This seems to be a common misperception between the two APIs and I believe the reason for this is with our v2 API you could generate an Access Token that lasted for a very long time. However; to generate the Access Token you still needed the user's Constant Contact username/password which is the exact same requirement in our v3 oAuth.

The only difference between oAuth in v2 and v3 is that our v3 Access Tokens expire after 24 hours and has to be refreshed. This does not require any extra user input. If you have the Access Token already then you can refresh it automatically.

I have to ask how did you get an Access Token for your v2 API sign-up form without the Constant Contact username and password?

[ChrisB73]

Oh, I did get access with CC credentials, just through the IO-docs page (https://constantcontact.mashery.com/io-docs) and not an Oauth flow. I think I get it now, thanks.

[Jimmy_D]

Hi @ChrisB73,

Using the I/O-docs page is still technically input from the user of the account; in this case you did the interaction and then probably hard coded the Access Token.

To be more secure we have lowered the expiration time of the Access Tokens from 10 years (v2 timeout) to 24 hours (v3 timeout). If you write your program correctly you can still do the customer input yourself and generate an Access Token which will then automatically refresh every 24 hours using the refresh portion of oAuth. Instead of harding coding these now you will just need to write the code to have them changed out.

If you need assistance with this feel free to reach out to us at webservices@constantcontact.com.

[SteveF71468]

We have started implementation of the v3 api and I would like to know how you get a new token everyday without having to use the I/O-docs pages.  I have the username, password, api key, and secret but I don't see how to use them to get a new token programmatically.  We are using php 5.4 and I have been able to used the I/O-docs generated token to retrieve the contact_list data but I cannot seem to get it to pass back a new token.

[Jimmy_D]

Hi @SteveF71468,

Regardless of the version of the API you are using you will want to use the oAuth flow to generate an Access Token. It sounds like you are using the v3 API if your token is expiring after a day. If this is the case you will want to make sure you include the refresh portion of the oAuth flow.

v2 oAuth: https://developer.constantcontact.com/docs/authentication/oauth-2.0-server-flow.html

v3 oAuth: https://v3.developer.constantcontact.com/api_guide/server_flow.html

[GRRA]

Each post like this seems to end the same way, with support pointing folks to the server flow docs page. Unfortunately, I've read it several times and still don't see how a refresh token solves the problem of server to server authentication without requiring user input. As I understand the process of refreshing the token as part of the server flow, you'd POST to the CC auth endpoint with the refresh token so you can obtain new access and refresh tokens. The problem is that in a server to server scenario the server would need to maintain the last refresh token that was obtained. That's not very realistic, partly because you could have multiple requests to an API trying to make this same auth request, and also ruins the ability to remain stateless.

I hope I'm missing something, because it would be a shame if CC isn't providing a method of server to server authentication via the new v3 API. It just seems like both auth methods assume a user is making the request instead of the scenario where another API is making the request. If the latter is not possible, I hope a support rep will confirm that and have it included in the documentation to prevent confusion.

[JamesV628]

I wanted to follow up and see if there's an update to @GoldenRetrieverR's last comment.

 I'm trying to implement a server to server setup, and I'm struggling with something that should be really straightforward, just post new contacts from our severs to CC's. But now it seems like I need to have a daily job whose sole purpose is to capture a new access token, which seems like a waste of time and resources. 

Can someone confirm if there's a more straightforward way to access the V3 API in a server to server setup? Or will I need to go with the aforementioned daily token refresh?

Further, server flow also seems to require a user to "grant access" to the application(judging by this: https://v3.developer.constantcontact.com/api_guide/server_flow.html?_ga=2.11847859.606592592.1583168...), which isn't going to be happening on a server to server basis. Is there a way to skip this step? This process is understandable for creating third-party apps(like Shopify), but this isn't what we're doing.

[Jimmy_D]

Hello @JamesV628,

We know there is a lot of requests for server to server authentication. This is something we are looking in to; however at this time we do not have this option available.

[Stacyw744]

Similar issue to https://community.constantcontact.com/t5/Developer-Support-ask-questions/V3-API-Retrieve-the-Authori... 

Surprised this is not a more common request.  

[IonH5]

I spend over $1,000 per month with CC, will likely be going to MailChimp as their API does not have this issue.

I can only imagine how much revenue this stupidity is costing CC.

[Courtney_E]

Hello IonH5,

Thank you for reaching out to Constant Contact API Developer Support. My team is here to assist outside software developers with questions about building into Constant Contact's API.

Your feedback and experience with this request is essential to improving our product, so thank you for reaching out to us regarding this matter.

We're currently making updates to our authentication system. This work would need to be completed prior to implementing additional authentication flows, however we are looking into them as future options. Some of the options currently under consideration include: Client Credentials flow, the Device Authorization flow, static refresh tokens, etc.

If you have a specific use case or  auth type that you feel would better meet your needs, we’d love to hear from you. If possible, please include what specific solution(s) you’re looking for, whether your app would only access your own Constant Contact’s account data or if it would also be used by other accounts, etc. You can reply here, or contact us directly via email at webservices@constantcontact.com.

Please have a look and let us know if you have any other questions!

[KyW]

Wow. Is this really still an issue? 

In the case that this issue has been resolved, I highly recommend CC support update pages like this because the internet is littered with forum discussions of developers saying this very standard use case is not possible with CC. 

If it is indeed still an issue -- it should really be addressed. M2M interaction is the most common use case in my work with email service APIs, and it is extremely easy to implement with services like Twilio Sendgrid or Mailchimp. To any devs visiting this page - I highly recommend using those services instead. 

[Courtney_E]

Hello KyW,

Thank you for reaching out to Constant Contact API Developer Support. My team is here to assist outside software developers with questions about building into Constant Contact's API.

API connections that use basic authentication to access the account via your username and password are no longer considered a secure enough option to protect our customers' data. Our current V3 API uses OAuth2.0, which is the current industry-standard for authorization. However, even with our previous/legacy API version, V2, you still had to grant access to the account to get an access token, which is what the integration uses to send data to/from your Constant Contact account.

OAuth2.0 is more secure and does a much better job of keeping your Constant Contact account data safe. Additionally, when you give their integration permission to access your account, it will show you exactly which permissions the integration is requesting to be granted (rather than just granting all permissions). V3 also uses tokens that are continuously refreshed to keep the connection encrypted and secure. 

Using V3, you should be able to fully automate your integration with the exception of the initial Authorization Request screen and redirect, which can only be accessed/authorized via a browser window and cannot be bypassed, but you should only need to authorize your account once (grant permission and exchange auth code for first token set). After the initial connection, your application will use the access token to make calls, and the refresh token to generate a new token set once the access token expires (24 hours), so the site credentials are not needed again after the first time.

The Authorization Request screen is only for the initial connection of a Constant Contact account to the integration, so for example, if you are making a sign-up form or integration that only connects to one Constant Contact account, only you would access the Authorization Request screen one initial time to connect your account, it isn't visible publicly to anyone signing up via the form.  When your users are accessing the integration/form, it will use the token set generated when you initially granted permission to access the connection. 

Please have a look and let us know if you have any other questions!