I am trying to post multiple messages in Yammer through only one account.
I have a service account on Yammer. Through that service account I want to post multiple messages on behalf of multiple users, but the REST API of Yammer has rate limits.
Is there is any way to post multiple messages without any hurdle of rate limits?
The rate limits cannot be exceeded, you'll get a 429 error for Too Many Requests. The rate limits are per app per user, so if you have a legitimate reason for posting a lot of messages in a very short amount of time, some creative thinking around these boundaries can help.
Related
I am trying to use postMessage for posting message in slack. I want to know the Rate Limit for chat.postMessage for a workspace.
Found this in the document:
chat.postMessage has special rate limiting conditions. It will generally allow an app to post 1 message per second to a specific channel. There are limits governing your app's relationship with the entire workspace above that, limiting posting to several hundred messages per minute. Generous burst behavior is also granted.
But what I could not understand is -
What is the several hundred messages?
After how many messages will the app be blocked?
Can anyone please guide me through this? Thanks in Advance.
Idea is to send notifications to users with direct messages. Because of that notification only bot need to be implemented. Reading documentation of MS Teams leads to information that we have 15000 across all threads in a data center (across multiple tenants).
Didn't find what are consequences when you hit this limits too often. Of course throttling mechanism need to exists, but with this limits I am not sure how to handle a large number of notifications I need to send from one bot across multiple clients(to be considered one bot per client if that is allowed to avoid this limit per data center for all).
Or any other idea how to handle notifications from one producer through bot to multiple consumers of those notifications on different addresses?
Is there any different pricing plan if you want to extend limits?
Currently the documentation just says:
If Connect API endpoints receive too many requests associated with the same application or access token in a short time window, they might respond with a 429 Too Many Requests error. If this occurs, try your request again at a later time.
Much appreciated!
Currently, Connect API rate limits are on the order of 10 QPS. This limit might change in the future and should not be relied on.
My application sends notifications to the customers in bulks. For example at 8am every day a back-end systems generates notifications for 50K customers, and those notifications should be delivered in a reasonable time.
During performance testing I've discovered that sending a single push request to C2DM server takes about 400 millis which is far too long. I was told that a production quota may provide better performance, but will it reduce to 10 millis?
Besides, I need C2DM performance marks before going to production because it may affect the implementation - sending the requests from multiple threads, using asynchronous http client etc.
Does anyone knows about the C2DM server benchmarks or any performance-related server implementation guidelines?
Thanks,
Artem
I use appengine, which makes the delivery of a newsletter to 1 million users a very painful task. Mostly because the c2dm API doesn't support multiple users delivery, which makes it necessary to create one http request per user.
The time to the c2dm server to respond will depend on your latency from the google servers. In my case (appengine) it's very small.
My advice to you is to create as many threads as possible, since the threads will be waiting for the IO over the network. If you every pass the quota, you can always ask permission for more traffic.
I'm working on an application that sends and receives SMS messages to and from its users. (Don't worry - it's not spam - every user of the app expects to send and receive these messages).
One key aspect of the app... If a user sends a message to the app, the app then sends that message out to every person on that user's "team". So, the app will be sending a receiving a pretty significant number of messages (I'm hoping for a few thousand users, and 5,000-10,000 SMS messages per day).
I've been experimenting with a number of options:
SMS to email
Connecting a mobile phone to my server
Contracting an SMS gateway
Option 1 is great, since it's free, but it's unreliable (apparently mobile providers queue these messages after SMS messages they can charge for, so they're frequently received late or lost)
Option 2 is also cheap, but the mobile phone can't keep up with the number of messages I'll be sending. Also, the mobile phone provider will consider this volume of messages excessive.
Option 3 is perfect, except that SMS gateway providers charge PER MESSAGE (usually $0.02-$0.06 per), which creates an impossible scaling problem. (Reminds me of the old business adage... "Sure we're losing money on every transaction, but we'll make it up in volume...")
So, long story short - how on EARTH did Twitter pull this off? They've been doing a similar thing (allowing users to exchange SMS messages with the app) since the beginning. Even if they negotiated an INCREDIBLE discount (say, $0.001 per message), they'd be paying an ENORMOUS cost to send the hundreds of millions of messages they handle.
Does anyone have any idea how they did this?
After a bit of Googling, it looks like Twitter has simply been signing deals with cell phone companies in various countries. For example (Twitter blog post link spam incoming):
Australia: http://blog.twitter.com/2009/12/sms-tweets-for-telstra-australia.html
Indonesia: http://blog.twitter.com/2009/11/sms-for-axis-indonesia.html
New Zealand: http://blog.twitter.com/2009/05/hello-new-zealand.html
UK: http://blog.twitter.com/2009/03/full-sms-service-for-vodafone-uk.html
Some more details about SMS in general here.