We all started somewhere! Share your experience on the Get Advice: Let's Get Started Sweepstakes thread and be entered to win a $100 credit on your Constant Contact account.

API Key for multi-user, multi-site application


API Key for multi-user, multi-site application

I want to get an API key from my account and tie it to a wordpress plugin which can then be installed on any wordpress website.


The API key requires a redirectURI -- this URI is custom for every wordpress install:





while I could generate that url and walk my users through generating their own API key with a custom redirect URL specific to their website, this is a _mess_.  I am confident that any instruction I could provide will at best be a hassle and at worst confuse all but technically savvy users.  


I desire to make my plugin usable by novice users looking to add constant contact support to their website.


How can I setup a cross-domain API key without the need for custom-tailored redirect URIs?


Looks like three-legged authentication is the answer as opposed to OAuth 2.0 through the CtCt wrapper


I'll post again if I have more questions or find out something interesting :)

Hey Chad,


Definitely let us know if you have questions. I've been working through some OAuth2 scenarios as well, and three-legged authentication does seem to be the best way to handle"novice-proofing" your OAuth2 authentication.

Nick Galbraith
Support Engineer
Regular Participant

Sorry for the bump. This came up on google.


Please explain how a 3 legged Oauth2 helped you? I am running into this problem developing an addon for a CMS.


I am very very very new to thos Oauth stuff, so please explain in detail. Is there another way?


All clients will have different URLs.


Thank you!

Unfortunately, in this set up there are only two potential answers:


1. Attempt us use the Client flow to intercept the 302 redirect in JavaScript.  This unfortunately doesn't work in some browsers due to cross site scripting security and is very risky.


2. Use a shared server model.  In this model, you would have the redirect URI hosted on a central server that knows the URIs of all your clients.  This could then receive the callback URI calls, process them and communicate back to the unique websites of each of your individual clients.  Indentification of the individual clients can be done as a query parameter for the redirect URI, such as:  redirect_uri=https://example.com?local_doman%26http://individualcustomer.example.com


We recommend the 2nd for both security and predictability of browsers.  It does require some additional communications on your side, but it is the best way to manage the authentication in a secure manner.  Notice that we added an optional query parameter to the redirect URI that is the local domain of the client you're authenticating.  It could just as easily be an ID number or anything you want to uniquely identify each client.  Query parameters are not validated for security purposes and can be dynamically generated per call.  The only requirement is that the exact same optional query parameters are passed on both stages of the call (request access and access token exchange).

Dave Berard
Senior Product Manager, Constant Contact

I want to study more about this information

Developer Portal

View API documentation, code samples, get your API key.

Visit Page