Hi Jimmy,   Thanks for your reply. I understand this could be for security reasons. I noticed in CTCT API we cannot revoke a refresh token and I guess that's why such auto invalidation is needed.   As to how often would this occur, from my experience it's very common to have subscription forms on websites nowadays, especially for marketing websites. And it's also very common, as you can imagine, that CTCT customers could run multiple websites and taking subscriptions from different websites and send them to different lists to segment contacts, it's how email marketing businesses work these days.    If there's no solution we need to make the customers aware of it (or our plugin will look buggy). And we then probably suggest users register their apps if that's the case. We'd really appreciate if it's something can be changed in the API, since we all know for non-techy people, registering their own apps will be a challenging work.   When you get the chance, can you let me know your team's decision on it? Thank you! ... View more

Hi Jimmy,   Thanks for your reply.    > In this scenario you can have multiple Access Tokens to the same Constant Contact account with the v3 API. I just tested this to verify it works.   Yes this works for sure. I can get multiple Access Tokens in my websites. The issue is that I CANNOT refresh tokens. When the access token expired and I tried to refresh token, only the last authorized website can get the tokens, but not the others. I got the 400 error with a message like this:   {"error_description":"unknown, invalid, or expired refresh token","error":"invalid_grant"} That's why I suspect the refresh token is invalidated every time when I authorize a new website. To reproduce this, can you try:   1. Authorize on multiple websites. 2. Refresh tokens on all sites. 3. See if you can get all sites the refreshed tokens, or if the error message shows up.    If it works at your end, can you explain in what scenario I could get the above error message? Thanks!  ... View more

Hi Jimmy,   > If they are for the exact same application then I ask why can the user authorize in two different places?   Yeah because it's a WordPress plugin so a user can install it on multiple sites with just one account.   From the answer of this approach:   > The best solution to this issue involves having a very minimal hosted page under your control that can be used as the redirect, which would then pass the request back to wordpress.   In this scenario, do you mean the user should still pass their own API keys instead of just using ours (we registered an app for this minimal hosted page)? If so, then it will work like:   1. We provide this minimal hosted page URL to our users. 2. Users register their application with our URL as the return URI. 3. Users pass their API keys to our minimal hosted page (for authentication) and get redirected to their website.   Can you clarify this a bit? Thanks! ... View more

Hi API support team,   Can you confirm if this method can still work with the v3 API? I found the refresh token will be invalidated/revoked once another refresh token is generated (say I have two sites and they are authenticated in the same app with the same CTCT account).   Thus I feel this "having a very minimal hosted page under your control that can be used as the redirect" method cannot work with v3 API anymore. Can you clarify this for me? Thanks! ... View more