I want to develop a .net service that will run on a schedule and query my company's campaigns for recently sent emails. This service will run completely independently of user input. I don't have our Constant Contact username and password but instead have the api key and access token that my colleague generated for me. Once the service is built and deployed, there will be no user input. Everything I read seems implies that OAuth is required but entering account details is not an option.
It's important to stress that this is my company's account and will not be used in any way by third-parties. The service is (for all intents and purposes) the account owner but does not have login credentials.
Can someone provide code samples as to how to go about this developing this?
Thank you for reaching out to Constant Contact's API Support.
Unfortunately I don't have any .NET code samples on this, however our OAuth process only requires the account owner connect once. They will get back an Access Token and a Refresh Token. Once you have these, you can programmatically use the refresh token to get a new access token without the need for the account owner to manually log in each time.
If you wish to view our documentation our OAuth, see here:
Please have a look and let me know if you have any questions!
Tier II API Support Engineer
I've read through the server flow docs several times and still don't see how you can you can use the refresh token to obtain new access and refresh tokens more than one time. As I understand it, once you use the refresh token to obtain a new one it becomes expired and can no longer be used. That seems to suggest the refresh token needs to be stored on the server so it can be used on the next request. If this is truly the recommended approach, it doesn't sound feasible if you have multiple users making the same request simultaneously. My preference is to keep things stateless and not store the tokens.
It seems awfully shortsighted if this is the only way developers can authenticate server to server. Please let me know if there's something I may be missing related to refreshing the token.
We use current OAuth standards for security purposes. Access tokens are good for up to 24 hours. Refresh tokens don't expire, but will become invalid if they are used or if the initial authorization flow is completed again. If you could use the same refresh token over and over, that kind of defeats the purpose of having a rotating access token.
When you use your refresh token, you get a new access token and a new refresh token as well. You then use the new access token until it expires, and refresh using the refresh token that was given at the same time as the access token you were just using.
Typically in a situation such as yours where you have multiple users making calls for the same Constant Contact account, you would have your server control all of your calls, storing the access and refresh token, and refreshing it when needed.
Please let me know if you have any other questions.
Tier II API Support Engineer
I'm still unclear why you would involve a refresh token in a machine to machine scenario. I already have the client id and secret - neither of which are public because this is running on a server and not in a user's browser. Why can't my application make a request to exchange those for an access token that expires after a period of time? Your system could then verify that access token before processing requests. An example of this can be seen on Auth0's site .
Unfortunately, your refresh token process is very inefficient for machine to machine scenarios like this and requires APIs to make several unnecessary requests. If I'm not mistaken, my API will need to request the current access and refresh tokens from my db, then make a request to the CC API only to find out the access token has expired. Now I have to make another request to your API using the refresh token to get another access token and refresh token, then save those tokens to my db again. Finally, I'm ready to make another request to the CC API with the new access token. While this is happening, I have to hope another user doesn't make the same request, since their request would fail as well and would cause them to do this same dance. Problem is it would be unnecessary since another user just fetched a new access token - but I really don't want to block requests while one user is getting a new token.
Did your team consider the approach of exchanging the client id and secret for an access token like Auth0 uses in machine to machine scenarios?