So they've clicked the unsubscribe link in a newsletter. In their profile it says, for example:
This person unsubscribed on Mar 24, 2017 2:40 pm
After receiving "Newsletter Test#6"
Great, but how can I tell programmatically, via the API, if someone has unsubscribed themselves? Is it even possible? The reason I'm asking is because you can't delete someone who has unsubscribed themselves. If you try, their data will be scrubbed but the email address will stay in your list. Furthermore, if you try to subscribe someone who has unsubscribed by clicking on an unsubscribe link, you'll get "john#example.com is in a compliance state due to unsubscribe, bounce, or compliance review and cannot be subscribed." So in this situation we should check if they've unsubscribed themselves, and if so we can set their status to pending which will send the confirmation opt-in email. Otherwise, we can subscribe them via API without setting their status to pending and sending them an email and requiring them to click the link in the email.
As you've noted, if you try to delete someone in a compliance state, the API will reject your request but unfortunately doesn't return any useful response indicating as such. On the other hand, if you try to subscribe someone in a compliance state you should get a response in json form with status of 400 and a corresponding message. In my case it looks something like this:
{
"type":"http://developer.mailchimp.com/documentation/mailchimp/guides/error-glossary/",
"title":"Member In Compliance State",
"status":400,
"detail":"johndoe#example.com is in a compliance state due to unsubscribe, bounce, or compliance review and cannot be subscribed.",
"instance":"1234567890abcdefg"
}
If you simply parse that response you can check for the value of status which is probably more reliable and forward compatible than the textual descriptors - and if applicable you can set member state to pending from there.
From Mailchimp support:
When a user is unsubscribed you'll see the parameter unsubscribe_reason and if it's an admin unsubscribe or an unsubscribe done via the API it will say "N/A (Unsubscribed by an admin)". However if it is done by the user it will often say "Unspecified" if they did not leave a reason or it may display a reason the user noted for unsubscribing. You can read more about the unsubscribe_reason parameter at the link below.
http://developer.mailchimp.com/documentation/mailchimp/reference/lists/members/
To expand on the answer from #nmit026, do a get-member-info api request and check for:
unsubscribe_reason == 'N/A (Unsubscribed by admin)'
In my opinion, this feels a bit hacky as the logic relies on comparison to a fairly specific string, but nonetheless, it is probably only correct approach at the moment.
Related
we have a chat bot that seems to be receiving messages from another bot. we'd like to ignore these messages, as responding to them leads to an infinite loop of ping pong between the two bots.
we were hoping to rely on activity.from.role as documented here, but it seems like that field is never set.
activity.from.id looks something like 28:app:00000000-dfae-4fe1-a068-80fe8fc61f2b_62b732f7-fc71-40bc-b27d-35efcb000000, and we are thinking that the only way to identify the account as a bot is by detecting the :app: in these IDs. this is sub-optimal, as this ID format is not part of the official API and could change at any time.
that said, how should we detect if an activity event is coming from a bot?
If you've to deal with potential bots from outside your organisation, a simple way could be to keep a dictionary of few last text exchanges indexed by userId or UserName in the Activity object. Then, at each POST received by your bot, check if the received text match fully one of the precedent message entries in this dictionary. If it is the case, then mark the related userId/UserName as a candidate for the bot role but continue to check further text exchanges in case a non bot user just said hi twice.
If the few following further exchanges doesn't meet anymore the full match requirement, unmark the userId/UserName as a potential bot. If there is marked UserId/UserName as candidate for bot role, apply the bot role to them if there's no more further exchanges past the full match entry or after a delay of your choice. For the latter, it might be useful to provoke a last text exchange after the delay to decide.
For the Watson/Eliza kind of bots, i recommended to check the speed of the exchanges, as far as i know, no human being can exchange more than twenty messages per second.
I am creating a Node/Express Webapp that would mirror a user's calendar. It would get a notification for every change in the users calendar, and would update the DB with the latest of that user's calendar.
Lets assume that we want to monitor john.doe#gmail.com. Kindly tell me if this is the best (and only) way to do it:
Set up for Push notification - While doing so, we provide (amongst other fields):
token - A plain-text that would be echoed back. This is where I can put something like 'calOwner=john.doe#gmail.com'
id - A UUID channel id
Upon every change, my webhook will get a push notification that would contain:
token : calOwner=john.doe#gmail.com
id : the channelId - I dont understand if this field alone can be used to trace this notification message back to john.doe#gmail.com
Now that I know john.doe#gmail.com has changed, I would do a list with a synchToken. This will return me the change in john's calendar since last synch
What baffles me here is that the seemingly important fields channelId and resourceId (which appears as x-goog-resource-id in the push notification header) are useless, and the only field that ties the push message to list is an optional plain-text field token .
Kindly tell me if this is the only way to track a user's calendar.
UPDATE
Thanks #KENdi for the answer.
My struggle was with the point that simply looking at a push notification message, there is no way to trace it back to john.doe#gmail.com . I now understand why such is the case, that a push notification does not contain the calendarId, but the resourceId instead (which, in plain terms is the event object). It is so because an event can be associated with multiple calendars, and hence multiple calendarIds. Hence, it is the subscriber's responsibility to maintain association of the channel to the calendarId that he had used to create the channel at the first place.
Yes, you are correct, you need the calendar push notification, to notify you about all the changes happened in the Google Calendar.
The purpose of X-Goog-Resource-ID is an opaque value that identifies the watched resource. And this ID is stable across API versions.
Check this SO question to know more about the purpose of X-Goog-Resource-Id.
I would like to use the Outlook REST API to display the messages in a mail folder and group messages by conversations, like you have in any modern webmail.
For example with inbox, I would request using a first query such as <mailuri>/inbox/messages?$select=ConversationId (by default it is reverse chronological order)
It is not sufficient to group this request results by ConversationId because some emails may not be in inbox (think of sentmails) or they may be paginated and not returned in the first page.
Consequently, for each distinct ConversationId I need to perform another REST request, for retrieving participants or simply counting the emails in the conversation. I may use the new batch request to do this.
There are a lot of requests involved. Is there a better solution ?
As you've probably realized the REST API doesn't directly provide a way to work with conversations as an entity. This is something that we have on our roadmap to improve.
With the current state of the API what you're describing is basically the right approach. You could possibly defer the second request to "fill in" a conversation until the user selects it.
You can actually use this endpoint to cover both inbox and sentitems
https://outlook.office.com/api/v2.0/me/messages/?$select=ConversationId & $filter=ConversationId eq '${params.conversationId}'
A web application sends an email on behalf of a UserA to UserB, using the new Gmail API (Users.messages: send).
The synchronous response contains threadId, messageId which are stored in the database.
We then query the history API for any changes in user's inbox (Users.history: list).
Is there an efficient way to get all the updates since last sync (new replies, read/unread changes)?
One implementation that we tried was to filter the history API results through a custom label. Unfortunately, we noticed that once a thread/message is tagged with a specific label any subsequent responses are not labeled automatically and new replies are not included in the history API response.
A second approach was to query threads using gmail advanced search for a particular label and date (e.g. after:2014/08/29 label:MY_LABEL). The problem was that gmail does not return threads that were created before 2014/08/29 but had a reply on that date.
Any scalable suggestions would be greatly appreciated.
Not sure I understand here, users.history.list was made exactly for this. Given a previous historyId, you can then call history.list(previousHistoryid), iterate through the results to find all the message Ids that have been updated since the previous historyId. Then call messages.get() on all of those--for any messages you already knew about you can just call format=MINIMAL (to see label updates), and for new messages you can use a different format to get the message content if you need it.
The graph api allows you to invite multiple friends to an event by using POST EVENT_ID/invited?users=USER1,USER2,etc. However the entire POST will fail if one of the friends in the comma delimited string has blocked this user from inviting him to an event.
The problem is that it does not tell you which friend(s) failed.
Thus making the multiuser POST totally useless unless we can find out which user is the offending user.
The docs say (https://developers.facebook.com/docs/reference/api/event/#invited),
You can invite users to an event by issuing an HTTP POST to /EVENT_ID/invited/USER_ID. You can invite multiple users by issuing an HTTP POST to /EVENT_ID/invited?users=USER_ID1,USER_ID2,USER_ID3. Both of these require the create_event permission and return true if the invite is successful.
So what exactly does
However the entire POST will fail if one of the friends in the comma delimited string has blocked this user from inviting him to an event
mean in your problem description – are you “just” getting false as an answer, with the requests to the other users actually being send – or does none of the users receive their invite, even though only one of them blocked it?
The first outcome would be annoying; the second one totally a bug IMHO.