custom sign-up form

[kevincarbon]

Hello,

Is it possible to create our own custom sign-up form that posts to the same end-point as a CC Sign-up Form created using the form builder? That way we can customize the form more, but still capture sign-ups to the same end-point so that CC can use the emails in Automations, etc..

When we created an inline sign-up form within CC I was hoping to get the full HTML that I could then edit, and just make sure it was posting to the same end-point, but it looks like the inline forms use CC's Universal JS to embed the form. I'm assuming I could decode that and just find the same end-point and post to it the same way but I wanted to get confirmation first before I spend time on it.

I hope that makes sense.

Please see this post for additional context: 

https://community.constantcontact.com/t5/Questions-Discussions/custom-inline-form-code/m-p/428619#M8...

[John__B]

Hello kevincarbon,

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.

There isn’t a way to edit the inline and pop-up sign-up forms beyond the customization that is available in the website UI, however, you could utilize our V3 API to build your own custom sign-up form. Below I’m including documentation for our sign_up_form endpoint, which has similar functionality to that of the inline and pop-up forms offered in the website UI.

Create or Update a Contact:

https://developer.constantcontact.com/api_reference/index.html#!/Contacts/createOrUpdateContact

While our expertise is with our API itself as opposed to its implementation within any particular programming language, we are happy to answer any questions pertaining to Constant Contact’s API endpoints, functionality, and documentation.

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

Regards,

[kevincarbon]

Hi John B.

Thanks for the response. I've been looking into using your proposed solution to add contacts to a list but the CC API doesn't appear to support any form of machine-to-machine authentication. All API Auth methods require user interaction to authorize the authentication. This doesn't make it easy to have our server/API post to CC when someone submits the form.

Do you have any suggestion? Or am I missing something? Please advise...

[kevincarbon]

It looks like CC doesn't plan to support true machine to machine (non-interactive) authentication which completely boggles my mind why they would make that choice. It is a massive limitation for us and many others I see posting online.

https://community.constantcontact.com/t5/API-Developer-Support/Authentication-for-non-user-interacti...

[Courtney_E]

Hello kevincarbon,

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.

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 each connected account once. 

Basically the only time you have to authorize via browser is when you initially connect the Constant Contact account, and from then on, the token set (access token and refresh token) are used to maintain the connection within your application.

For initial connection:

-Create auth request URL (make sure to include the offline_access scope)

-Navigate to that URL in browser, it will have you log into the Constant Contact account you want to connect, and grant permission, which returns a code

-Call the Token endpoint to exchange the code for an access token and a refresh token

If desired, you could even perform the initial authorization externally (in a program like Postman, or similar), and then just plug the access token and refresh token into your program.

Additionally, we now offer Long Lived refresh tokens, which basically ensure that the refresh token returned each time is the same value (the access token still changes), which can help prevent authorization 'breaking' in the long run due to a wrong or old value being used. I'll add more info about them at the bottom.

For maintaining the connection:

-When the access token expires after 24 hrs, a refresh token is used to make a call to the Token endpoint to return a new access token and refresh token.

A few different ways that developers maintain their token sets include:

-Refreshing the token set on a schedule

-Checking to see if the access token is expired by parsing  the JWT access token for the expiration date/time, and then based on that, either continue with the endpoint call or refresh the token set

-Attempting the endpoint call, and if it fails due to invalid token, then refreshing the token set and attempting the endpoint call again.  This option may be simplest, but it also uses additional endpoint calls.

About Long Lived Refresh tokens:

When using the new OAuth2 flows that are available for V3 using our recently implemented authorization management service, the access token lifetime is now a static 24 hours, and you have the option of using rotating refresh tokens or long lived refresh tokens. 

Rotating refresh tokens can only be used once, and generating a new set of tokens causes all previous refresh tokens to expire, so each time you refresh the access token you will get a new refresh token value as well.

Long Lived Refresh Tokens (which can be configured within your V3 key’s settings), allow you to use the same refresh token continuously to generate new Access Tokens. You can use the same configuration as you would for the rotating refresh tokens if desired, you’ll just get back the same refresh token value each time when receiving your new access token.

Both types of refresh tokens must be used within 180 days of generation, after which they will expire. (If the long lived refresh token is used within that time frame, it will remain active and you can continue using the same value.) 

While we generally recommend using rotating refresh tokens (as they're more secure), using a long lived refresh token should alleviate many of the situations that we've seen reported where a refresh token becomes invalid, and then requires a new authorization request. 

-Navigate to https://app.constantcontact.com/pages/dma/portal/ 

-Log into the user that created the key you are wanting to edit

-Open key to edit

-Click "OAuth2"  tab

-select "Long Lived Refresh Tokens"

-Click save in upper right

-You will need to authenticate and reconnect again after making this change in your key's settings

Please have a look and let us know if you or your team's developers have any other questions!

You can also reach our team directly/securely via email at webservices@constantcontact.com