I tried to make multiple subscriptions to a single user, to test out how many subscription requests i can send until throttling occurs. I used the following code:
for (int i = 0; i < 10000; i++)
{
try
{
var request = graphClient.Subscriptions.Request();
var result = await request.AddAsync(
new Subscription
{
ChangeType = "created,updated,deleted",
NotificationUrl = notificationUrl,
Resource = "/users/" + userId + "/" + resource,
ExpirationDateTime = DateTimeOffset.UtcNow.AddMinutes(4230),
ClientState = "my-subscription-identifier"
}
);
AddOutputMessage((i + 1) + " Created Webhook", Color.Blue);
}
catch (ServiceException serviceException)
{
AddOutputErrorMessage(serviceException);
}
}
The throttling limit per user per app is 10000 in 10 minutes (as described in another stackoverflow post). I already tested this limit by making some requests to a single users calendar and contacts where it seems to work.
I was able to make 220 subscriptions until throttling occured (tested it three times). Even though that seems to be a little low, my end goal is to make multiple subscription requests for multiple users (for example 1000 subscriptions to a 1000 users), so it wouldn't be a problem if this throttling limit is for a single user only.
The throttling (HttpStatusCode 429) service exception for the subscriptions request also contained the error code 'ExtensionError' which i couldn't really find in the doc.
What i want to know is:
What are the throttling limits for the '/subscription endpoint'?
Especially after how many requests does throttling occur? (per user and overall per app) e.g. if i want to make subscriptions to 1000 users will i be throttled after 220?
What is an 'ExtensionError'?
ExtensionError is actually an OAuth error category. Expand the Message string to see if it has more info.
I'm checking with the code owners to see what the subscription limits for REST are.
Related
I'm working on implementing MFA in my pet-project. As I understand from Twilio Verify docs (https://www.twilio.com/docs/verify/api/rate-limits-and-timeouts#code-validity-period) it has some limitations: the code is valid for 10 minutes and I can only send 5 messages in this 10 minute time span (https://www.twilio.com/docs/api/errors/60203). Also, I found a way to avoid this restriction by updating verification status to "cancelled". The code in C# looks like this:
static async Task TestingTwilioLimitations()
{
VerificationResource verification = null;
for (int i = 0; i < 3; i++)
{
verification = await VerificationResource.CreateAsync(
to: "phone number",
channel: "sms",
pathServiceSid: serviceSid
);
Thread.Sleep(TimeSpan.FromSeconds(10));
}
await VerificationResource.UpdateAsync(new UpdateVerificationOptions(serviceSid, verification.Sid, VerificationResource.StatusEnum.Canceled));
for (int i = 0; i < 3; i++)
{
verification = await VerificationResource.CreateAsync(
to: "phone number",
channel: "sms",
pathServiceSid: serviceSid
);
Thread.Sleep(TimeSpan.FromSeconds(10));
}
}
This code allows me to receive 6 messages with codes, despite the limitations of 10 minutes and 5 attempts to send the code. So, the question is, can I use this trick? It allows to spam people (I'm not going to do that, just wanted to be able to configure max send attempts and code validation time from my side), and I'm afraid of being banned by Twilio Verify for using this API calls.
This blog may help you.
How to test Twilio Verify without getting rate limited
Otherwise, no way to change the behavior.
I have found many links regarding unread message count but most of them are pointing at older release code.
From Current REST API v2, found this code.
.twilioClient
.chat
.services((process.env.TWILIO_CHAT_SERVICE_SID || config.TWILIO_CHAT_SERVICE_SID))
.users(req.params.userSID)
.userChannels
.list({}, (error, result) => {
for (var item in result) {
let count = item.unread_messages_count == null ? 0 : item.unread_messages_count;
totalUnreadMessages += count;
}
But the code shows unread_messages_count as null always and I searched about **consumption horizon ** from here.
https://www.twilio.com/docs/chat/consumption-horizon
But dont know how to set consumption horizon or someother thing to make this work through API.
Twilio developer evangelist here.
As the documentation says:
Note: Chat does not automatically set the Consumption Horizon. If you do not explicitly set this within your application, no Consumption Horizon will exist for a User within the Channel. Without a Consumption Horizon, your user's Consumption Horizon (read status) will not synchronize correctly across clients. If a user does not have a Consumption Horizon set on a channel, getting unconsumed messages will always return 0. If a member of a Channel has no consumption status, their last consumed index and timestamp will be null or 0 depending on the platform.
So, in order for there to be a consumption horizon, you need to set it via the SDK. In JavaScript, that looks a bit like:
activeChannel.updateLastConsumedMessageIndex(someMessageIndex)
.then(function () {
// consumption horizon updated
});
where activeChannel is a channel object that your user has joined and someMessageIndex is the index of the message that your user last read.
The consumption horizon for the channel must be set via the SDK for it to show in the REST API.
I've read the Twitter REST API docs, I know that it says you can fetch 200 at a time to a max of 800. However... I can't. I'm pulling 200, using the last tweet as max_id and then sending another request but I only receive the last tweet from the first request, not the remaining from my supposed 800 limit.
So I did a little research and I found that when I was sending more direct messages from other accounts my other direct messages were disappearing (i.e, if I had 200 received messages from an account called "sup," and I sent 5 messages from an account called "foo," "sup" would only show 195 direct messages and "foo" would show 5. Those 5 messages would disappear from "sup" in both the twitter DM window, as well as from the API calls.
I'm using Twython to do this, but I don't believe that switching back to requests would change anything, as I can visibly see the messages disappearing from the chat log. Does that mean that Twitter only stores 200 total DM's? Or am I doing something completely wrong.
This is the code I was using to pull for direct messages. Keep in mind that I still don't know how to explain DM's disappearing in the twitter DM console.
test_m = twitter.get_direct_messages(count=200)
i = 0
for x in test_m:
print 'dm number = ' + str(i) + '| dm id= '+ str(x['id']) + ' |text= ' + x['text']
i += 1
m_id = test_m[-1]['id']
test_m_2 = twitter.get_direct_messages(count=200, max_id=m_id)
This code will return test_m as an array of 200 items, and test_m_2 as an array of 1 item, containing the last element of test_m.
Edit: Well, no response yet but I figured I should add that this method successfully returns more than 200 messages for the other api calls I've made (user timeline, mentions timeline, retweets). From my testing I have to assume that only 200 incoming messages are stored by twitter throughout all DM interactions. If I'm wrong, let me know!
Brian,
Twitter stores more than the last 200 messages, if you were to delete 1 of the Direct messages using destroy_direct_message, then you can access 1 addition old direct Message.
Deleting 100 old Direct Messages will give you access an additional 100 messages etc.
I neither make max_id nor page work either. not sure if the bug it in Twython or Twitter ;-(
JJ
Currently, the API stands you can get up to the latest 3200 tweets of an account but only the 200 latest received direct messages (direct_messages endpoint) from a conversation or the 800 latest sent direct messages (direct_messages/sent endpoint).
To answer your question, I do not think there is a limitation of the number of direct messages "stored" by Twitter. Recently, I have been able to retrieve a complete conversation with more than 17000 direct messages (and all the uploaded media) using this tool that I have created for this purpose.
To address the Rate Limit Exceeding issue in code, I am just wondering, can I do this?
do
{
Log.Info(this, string.Format("Fetching user timeline statuses for {0}", screenName));
var twitterService = new TwitterService(_consumerKey, _consumerSecret);
twitterService.AuthenticateWith(_accessToken, _accessTokenSecret);
ListTweetsOnUserTimelineOptions listTweetsOnUserTimelineOptions =
new ListTweetsOnUserTimelineOptions();
listTweetsOnUserTimelineOptions.ScreenName = screenName;
listTweetsOnUserTimelineOptions.IncludeRts = true;
Thread.sleep(50000);
catch (Exception e)
{
Log.Error(this, string.Format("exception happened whille calling Twitter Service{0}", e.StackTrace));
}
} while (result.Count < count);
According to the API, the time is divided in to 15 minutes window now. So, by putting in a Thread.sleep() would that be OK? because Twitter documentation doesn't really provide any code example.
All help is greatly appreciated.
Yes you can, but I'd look for a more sophisticated task scheduling, like this one: https://stackoverflow.com/a/14945407/253468
Also revisit the Twitter API docs, I think it's not one request you can send every 15 minutes. Divide the number of times you can request over 15 minutes to know how often you can run your scheduled task.
I am using Amazon-SES api for sending email to clients. It's very successfull but i have to send different body for each client. When i start to send mails about 200.000 clients, how the code below look like ? Is it loop 200.000 times or can i prepare an object and send one time (like n:n system, now it's 1:n).
var clientList=new List<String>(); //200.000 mail adress
foreach(var to in clientList)
{
SendEmailRequest email = new SendEmailRequest();
email.Message = new Message();
email.Message.Body = new Body();
email.Message.Body.Html = new Content(bodyhtml);
email.Message.Subject = new Content(subject);
email.WithDestination(new Destination() { ToAddresses = new List<String>() { to } })
.WithSource("mysite#mysite.com")
.WithReturnPath("mysite#mysite.com");
SendEmailResponse resp = client.SendEmail(email); //that's 1:n
}
SendEmailResponse resp = client.SendEmail(emailList); //that's n:n but it's a wrong usage
How can i send n:n algorithm in Amazon SES ?
Application is Asp.net MVC 3. So can i use Asynchronous Controller ? Is it good idea ?
Assuming you have production access for Amazon SES already (see What should I do after I'm finished testing and evaluating Amazon SES?) and a sufficiently increased Sending Quota to send 200.000 mails/day in the first place (see How Amazon SES Sets Sending Limits), the respective limits are documented for the SendEmail action:
The total size of the message cannot exceed 10 MB.
Amazon SES has a limit on the total number of recipients per message:
The combined number of To:, CC: and BCC: email addresses cannot exceed
50. If you need to send an email message to a larger audience, you can divide your recipient list into groups of 50 or fewer, and then call
Amazon SES repeatedly to send the message to each group. [emphasis mine]
Please note: It is strictly recommended to use Bcc: only for this kind of mass mailing operation, else your users will see their mail addresses exposed to each other and I can guarantee they won't be amused at all!
So you could prepare mails with 50 Bcc: recipients at a time, dropping the outbound mail amount for your use case to about 4.000, which is a considerable improvement already. However, please note a respective AWS Team response to Increase sending limit, and question on FAQ:
if you're sending to multiple ISPs [...], I would recommend
sending to one address at a time since certain ISPs are sensitive
about multiple addresses on the BCC: line in large quantities. [emphasis mine]
Whether or not this warning applies depends on your use case as usual (e.g. you might be able to shard the mails by ISP etc.).
Doing it asynchronously is fine and likely useful, but you need to ensure to stay within your Maximum Send Rate (mails/second) limit as well. These limits are visible in the SES tab of the AWS Management Console, but available via the API as well of course (see Monitoring Your Sending Limits for details).