Mailchimp API (v1.3): addresses added with listSubscribe() don't appear in dashboard - api

I'm using Mailchimp's API (v1.3) to add email addresses to a subscriber list on one of our sites. Obviously, I'm using listSubscribe() and everything is working fine, for the most part (read: API call returns true, all of the data I'm sending to Mailchimp gets added/updated correctly).
The problem, however, is that whenever a new address is added, the things that are normally supposed to happen (in particular: email notifications to list manager, addresses showing up in the dashboard list status stream) aren't happening.
I've looked around for quite a bit and haven't found anyone with the same issue. Any ideas?

The default action of listSubscribe to add a subscriber is opt-in. This means that when you submit a listSubscribe the subscribed user will get an email asking to confirm their opt-in.
If the user does not follow the link in the email then they will not appear in the dashboard.
You can bypass this by using:
'double_optin' => FALSE,
http://apidocs.mailchimp.com/api/1.3/listsubscribe.func.php
However this is only recommended for very occasional circumstances (essentially where you are handling the opt-in).
In my case I am not activating a user account until they verify their email address. If let the opt-in email be sent then the user is going to get a number of emails from my web app. I'm being very careful to make sure that they're verifying their subscription and all subscription stuff is being processed by the web app (eg a user unsubscribes within the web app, not via MailChimp).

I talked to the Mailchimp support, and they said those actions won't happen using their public API; there is no way to trigger them.

Related

Email addresses automatically getting added to Global Unsubscribe after API send

I have a weird problem where some email addresses are automatically getting added to my Global Unsubscribes after each API send to that address.
The initial email gets sent and delivered, but then the receiving address is automatically added to the group, and any subsequent API sends will cause the email to get dropped immediately. I have to manually remove the addresses every time.
Does anyone have any ideas what could be causing this?
I had the same issue, it seems like some spam filters "click" all the links that are in emails. I also contacted sendgrid support and they confirmed that this might be the case and there is nothing they can do about it.
Unfortunately the only solution I could come up with is a two step unsubscribe, that you have to implement yourself. Creating unsubscribe links that redirect you to your own server, where you add a confirmation step.

How can I customize AWS Cognito default confim message?

I am using AWS Cognito to verif users' emails by sending verification links to users' email. After users click the links, a default confirm message "Your registration has been confirmed!" is shown. Is there a way to customize this message?
Thank you!
Currently (late June 2018) this still appears to be not supported. It is a pain because users should be redirected to the app in question after confirming their account, but currently they must navigate themselves.
There is a proposed workaround (essentially customizing the confirmation e-mail to send the user to your own API that performs the confirmation in a lambda), but I have not tried it. There does appear to be demand for this and AWS is aware of it as a feature request. I've seen them adding more customization abilities to the Cognito console recently, so keep checking there for updates.
If you're using the Cognito-hosted pages, you only get what you get which is going to vary depending upon when you're reading this message. Here in late 2019, the Cognito-hosted page redirects successful logins and confirmations (of phone/email) to whatever you specified as the redirect URL.
My issue is similar. After the user signs up, I want to customize the CSS of the confirmation page which doesn't appear possible. The confirmation page isn't great because it means that if the user closes the confirmation code entry tab before entering it, then their email is in the system but unconfirmed. And there's no way to confirm it. It's stuck. I'd like to have giant red letters that say "DO NOT CLOSE THIS CONFIRMATION TAB. CHECK YOUR EMAIL FIRST!" but there doesn't appear to be any way to do this at present.
The solution to any of these "how do I customize X of the Cognito-hosted flow" is either (a) look in the available UI customizations or (b) if they aren't available, change to an entirely hosted flow (still Cognito... just using your own pages and URLs).

Allow user to choose how they receive forgot password code

Tried searching for this in Amazon's docs but couldn't come up with anything.
Assuming that both email and phone number are checked in the verification section of the user pool. If the client app wants to allow the user to choose how they receive the code (assuming they've forgotten their password) - how do we get Cognito to handle that? Is there a way of getting the forgotPassword method to select a route (email or SMS)?
From some early testing, it seems like it always goes one route if both are available. I do see that Amazon themselves have made this available on their site though, so hoping that it should be possible?
For this example, we can assume that we've got a verified email address and phone number for that user.
I am on the Cognito team. Currently the behavior is that if both phone number and email are verified, the code goes to the phone, hence phone number is given preference and there is no way to select where the code actually goes. However, we have heard this request in the past and I will add a +1 to the feature request on your behalf.

Payment confirmation using Authorize.net in VB.NET

I have a single authorize.net account, and I have 5 different e-commerce applications tied to that account. Some are posting from a public site and some are posting from managed access sites. I am using SIM and I have read about the Relay Response, but as far as I can tell I can only have one URL listed. That will not work for me as I need a different URL for each different point of entry into the e-commerce system.
My problem at the moment is that I need to update a datafield via a guid upon successful payment completion to confirm purchase of a digital item, but if I put in a relay response page it is getting sent to all my access points and throwing errors. Other parts of the e-commerce system need to send different emails upon completion etc, plus all the urls are different at the top level.
Is there some other way of accomplishing this task that I am overlooking?
Use Silent Post*. It's Authorize.Net's equivalent of Paypal's IPN. It will only post to one URL per account but it happens behind the scenes. This means you can send a custom flag along with each transaction identifying which site the purchase is for and then have it respond accordingly (e.g. send emails, update database, etc).
*I am the author of this content

Disallowing link from opening in Forward email

we have a use-case wherein a notification email is sent out in response to some postings on forum. This notification emails carry a AHREF link which basically allows to launch the post page from the email itself. Additionally, these links carry an authentication token so that the user don't have to sign in when opening the page. This works fine in the normal use case, but in the scenario when the original recipient forwards the email to some other account we are not sure how we identify that the link is opened from forwarded email address. Can somebody provide some insight ?
There is principally no way for you to detect that a link was clicked in an email that was forwarded vs. an email that you sent directly to someone.
Do not put an authentication bypass in the link if the need to secure your content outweighs the need for user friendliness.
You can weigh allowing the user, once they log in, to set a persistent authentication cookie in the browser they logged in from. That way, if they click a link in an email and that cookie is set, they can get directly into the website. StackOverflow.com works that way, which is convenient and the downside risk is not too great. Fortunately my bank does not work that way. The potential for loss is much greater with home banking.