I am trying to upgrade from V2 to V3, my "get contacts collection" URL looks like this:
xxx=My API Key
In V2 I was also setting this authorization header:
xxx= My Authorization (not sure what this key/code is called)
For V3 I also generated a "Secret", does that need to go somewhere?
When I GET to the URL listed above, I get no response at all. In the documentation, what I have matches, except the example doesn't show you how to add the API Key (I am assuming its the same way as V2 but it doesn't say how in the docs):
I suspect the problem is that my request isn't authorized. In the examples on this site:
...they don't show you how to authenticate, because you have to be logged into that site, then the authentication parts of the request are inserted automatically.
However, because of that, I can't see how to do it. Where can I get an example showing how to send the request with the correct authentication embedded?
The v3 API uses the same authentication method as our v2 API did with one exception. The Access Tokens expire more frequently now so there is a method to refresh them. Here is the location for our oAuth documentation.
Sorry, but I am lost. My script was working fine with V2 but now it is broken in V3. Where is an example showing how I code authentication? The examples in the V3 documentation don't show how to do this. I can't even find where it says which values I have to pass (API key? Secret?, etc.).
OK, so it seems the value after "Bearer" in my authentication is wrong. I was able to get this by looking into the Network connections from the Try It button on your website. I don't know where I would have gotten that value otherwise, because it wasn't in the My Applications info.
Using the Try It button does authenticate and create an Access Token which is the Bearer ID that you located by checking the Network tab. Please keep in mind that will expire and you will need to get a new one.
That is why we suggest that you write your own oAuth code and we have provided both cURL and PHP examples if you check on oAuth sections of the API Docs. You can scroll through that link and there will be example sections with tabs to show you both of the coding examples to write your own oAuth flow.
I'm doing my best with this but I'm struggling a little bit.
The first thing I need to determine is if I need Server Flow or Client Flow, correct?
My app works like this:
• User fills out a form on our website.
• There is an ASP script on the server which accepts the incoming form data via AJAX.
• The ASP script writes data to our internal database.
• Then, the ASP script sends a GET request to check if the user is in our Constant Contact contact list.
• If Yes, then do a PUT to update their information.
• If No, then do a POST to add the user to our contact list.
The GET, PUT and POST are done with REST connections to the API. The user on our website never sees any of this happening, it is all behind the scenes.
Upon completion, we display a simple "success" message to the user.
I have tested all of this and it works fine. The last piece I need to do is setup oAuth so that I have a valid Access Token (as you indicated, the one I got from the Constant Contact website expires after a while).
So based on all this, can you suggest Server Flow vs. Client Flow? I obviously don't want the user on our website to have to leave the page they are on, for any redirects and so forth, as we are trying to do all of this via AJAX and REST.
You would want to use server flow. The client flow would be used in a scenario where your application runs solely on the clients end.
In your scenario you are running everything on your end and storing data there as well. The only thing the client will be redirected for is they will be prompted once to enter their Constant Contact username and password. Once they do this and Allow your application to connect to their account then your application will get an Access Token to connect to their account. After that the oAuth flow has steps for you to refresh that token as needed.
Please walk me through this.
Are you saying my script can't just add the user to our Contacts? Maybe I'm not sure what you are referring to when you say "client". Who needs to login to Constant Contact, do you mean the end user or the Constant Contact account to which my script is trying add to Contacts?
Why would either the end user (who probably doesn't have a Constant Contact account) or my script need to login to the Constant Contact website? Is it not possible to have my script/website pre-registered (via My Apps, API Keys, etc.) so that isn't necessary?
With the Constant Contact API V2 I was able to add users at will to our Contacts. The end user did not have to login to Constant Contact, nor did my script. As long as I had authentication (API Key, etc.), I could do all the REST commands behind the scenes.
I'm trying to determine, if I go through all of this oAuth setup, if the API is even going to do what I want it to do. I don't want anyone on the website redirected, we are trying to make this work seamlessly. I understand the importance of better security, but it seems that key functionality is missing here, unless I am misunderstanding what you are saying.
Your integration needs to connect to a Constant Contact account in order to know where to add the email address. The way that your integration connects to the account is through oAuth; the end result of oAuth is to get an Access Token.
The API Key allows your integration to talk to our system. The Access Token tells our system which Constant Contact account to send/retrieve data from.
It sounds like you are making a type of sign-up form. In that situation all of the authentication would happen behind the scenes. The "client/people" that are signing up do not have to authenticate. Your integration aka script is what needs to authenticate. In the v2 API you did this by using the API Key and Access Token which you also may know as a Bearer number.
It may be beneficial at this point to have you email us at email@example.com so you can provide us your specific information and we can give more detailed specifics that should not be shared publicly.