Problem
Using the Twilio REST API, I want to request only messages that I haven't downloaded yet. It seems the cleanest way to do this would be to download only messages after a specified SID.
Information not in the docs
The Twilio filter docs don't have this option. They only describe to, from, and date_sent.
However, it appears that Twilio does have this feature. You can see in their paging information, that the the nextpageuri contains AfterSid.
When browing the website, the URL contains /user/account/log/messages?after=SMXXXXXX
What I've tried so far
Using the twilio-ruby client, I have tried the following without success:
list = #client.account.sms.messages.list({after: 'SMXXXXXX'})
list = #client.account.sms.messages.list({AfterSid: 'SMXXXXXX'})
list = #client.account.sms.messages.list({after_sid: 'SMXXXXXX'})
From Dan Markiewicz - Twilio Customer Support
Unfortunately, we do not support filtering by this field in our API at this time. Your best option would be to get the DateCreated info on the SID you want to filter by and then use that to filter the messages by only those sent after that date. Since the date filter only supports filtering down to the day, it may return some number of unwanted messages that were sent that day but before the message you want to filter by. However, each message in the list will have a full date_created field down to the second, so you should be able to filter these out fairly easily on your end. This should produce the result you need.
After looking at the documentation you outlined, it looks like what you want to accomplish can't be done by the twilio-ruby gem. This link shows which filters are supported by the list method inside the gem in regards to messages.
If you look at the source here, starting on line 45 the gem uses next_page_uri as a way of determining the offset of where the next page should begin. For instance:
calls = twilio_client.account.calls.list # returns the initial set of calls.
calls.next_page # this uses next_page_uri to return the next set of calls internally.
This isn't something that can be changed via the gem currently.
Related
I'm trying to display all user's conversations sorted by last message creation date and I'm a little bit confused.
I see getSubscribedConversation method in docs (https://media.twiliocdn.com/sdk/js/conversations/releases/1.1.0/docs/Client.html#getSubscribedConversations__anchor) but it says nothing about page size and sorting. It returns paginator so I assume it doesn't return all conversations at once.
On the other hand I see some examples in twilio github projects where conversations are added to the list only by listening for conversationAdded event (which indeed fires even for previously created conversations) but it doesn't seem like a clean solution - if user belongs to 50 conversation then I should handle every single event and rerender the list 50 times?
To sum up, I have following questions:
Does getSubscribedConversation returns all user's conversations at once?
If no, then what is default page size and is it possible to change it (together with sorting)
If getSubscribedConversation return paginator indeed - wouldn't it break if I add conversation from conversationAdded event in the meantime?
I can't answer all your questions but I can give some insight on a couple -
From what I can tell, getSubscribedConversations returns 50 Conversations. I have not found a way to change that limit or sort it (I'm not entirely sure in what order Twilio returns them even).
For a project I'm working on we need Conversations sorted in order of recent message. The way I'm currently dealing with it is by storing the most recent message on an attribute on the Conversation. I also initialize the app by loading all the conversations with a recursive function.
Hope that sheds some light for you.
My intention is to build a Machine Learning program that will give a recommendation for archiving email item by reading all previous email history.
For that, I am trying to read all the email item from:
https://graph.microsoft.com/beta/me/messages
First I am getting the total number of email items in my account using /messages?$count=true which returns 1881 as the result.
Then I am trying to get all the 1881 item using:
https://graph.microsoft.com/beta/me/messages?$top=1881
But the problem is that returns 976 email items. Where are the rest of the email item? How I can find them?
Are you getting a #odata:nextLink property in your response?
If that's the case, you might need to send another request with a skiptoken parameter. It should contain a value from the #odata:nextLink response property.
On the "paging" documentation page - https://developer.microsoft.com/en-us/graph/docs/concepts/paging - it is specified that different APIs have different max page size. It's possible that the endpoint for fetching emails does not support a page size of 1881. In that case, you might need to access a second page of the results.
Another suggestion is to replace beta endpoint with the V1 API call because me/messages is available there also - https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/user_list_messages
I am trying to get the parent message of a threaded reply with the Slack API. When a new reply is put, it has a "thread_ts" attached to it, which corrsponds to its parent message's "ts". I tried to do a searchall with the ts as the query but this didn't work. How would I do this?
See Slack's docs on retrieving a single message with channels.history. This "selecting 1 item from a range" approach should also work with other channel history methods and conversations.history.
The easiest way is to provide the thread_ts value you want to look up as the latest parameter to conversations.history, along with the containing channel ID as channel, and a limit of 1 to ask for a single message. You will need the corresponding *:history scope to make the request.
Example:
GET /api/conversations.history?token=TOKEN_WITH_CHANNELS_HISTORY_SCOPE&channel=C2EB2QT8A&latest=1476909142.000007&inclusive=true&limit=1
I'm using Microsoft Graph to get a list of messages for a user.
I'm using the following URL
https://graph.microsoft.com/v1.0/me/mailFolders/inbox/messages
One important thing that is returned by this is the meetingMessageType when the message revolves around a meeting request.
I would also like to get the uniqueBody of the message. However, that's not provided by default. One needs to specifically ask for that field. I can do that by adding ?$select=uniqueBody to the URL.
However, that now means that I need to add the rest of the fields I want to the $select query parameter. That's not a big deal until I run into meetingMessageType. Microsoft Graph returns:
Could not find a property named 'meetingMessageType' on type 'Microsoft.OutlookServices.Message'.
What can I do to ensure I get both uniqueBody and meetingMessageType?
Try this:
$select=uniqueBody, microsoft.graph.eventMessage/meetingMessageType
Yogesh's answer is close but will result in a Only one level select is supported error.
As long as you don't care about the value of meetingMessageType, you can use this select:
$select=microsoft.graph.eventMessage, uniqueBody
You'll note that the results no longer include meetingMessageType as a property. The list however is limited to only those messages that are eventMessage, effectively giving you a result set filtered to only show meeting requests.
Is there a method to return a specific attendee's information by sending:
1) the attendee's email address
2) my user_key
3) my app_key
I could do this by searching the returned xml from this "event_list_attendees" method, however, I would prefer to only receive the one result (not hundreds for each call).
Note: I work on the platform team at Eventbrite
Currently there is no way to search for a specific attendee with event_list_attendees.
However, you can cut down on the amount of data returned by paging through the results until you have found the attendee or using the modified_after parameter if you know when the user was last updated: http://developer.eventbrite.com/doc/events/event_list_attendees/
I realize this limitation is non-ideal. We're actively working on building a new API which is more RESTful and does not have issues like this.