Hopefully I'm not the only one having this issues. When I request meeting time suggestions, which includes an attendee and time constraints, I get a response of 5 meeting suggestions. The issues is, that the slots have a gap in time, some times several hours. However, all attendees have that gap time as free; additionally, if I change the duration or increment the time one direction or another, the missing time slots show up. On a related note, is there a way to request more than 5 meeting time suggestions?
I think the perceived "gap" here is because you're expecting the meeting suggestions to be returned in chronological order, which is not the case. The FindMeetingTimes API tries to infer the user's preferred meeting times based on their past meetings, and the meeting suggestions are returned sorted by what the API thinks would be the most preferred. It's most likely that the "missing" time slots are lower down in the ranking, and you're not seeing them because you are only getting the default 5 results back.
You can request more results by including the maxCandidates parameter in your request body. See https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/user_findmeetingtimes#request-body for details.
Related
I have reached the Daily Quota Limit, and have submitted the Quota Increase Form.
After seeing the confirmation notice of my submission, I have not heard or received an email from them.
Is there any other solution to this issue? How long does it usually take for them to get back?
With things considered, we may have to increase the daily quota up to 100,000.
Is there a way to collect multiple data from a single quota?
My website mainly involves collecting view counts of videos through video IDs.
I have submitted the YouTube API Services - Audit and Quota Extension Form.
Thank you in advance
The time to get the quota increase varies greatly. It kind of depends on how back logged the team is.
In the beginning when they reduced it to 10k and I applied for mine it took more then three months.
These days I think you should get something in less then two weeks but don't hold me to that I dont work for YouTube this is just my experience.
Oh and just check it now and then they may apply it before the actually send you an email saying that they are going to apply it.
I only have 15-20 messages in my inbox for June 20. But when I run a search query for that day
https://graph.microsoft.com/v1.0/me/mailFolders/inbox/messages?$search=" received = 2019/06/20"&$select=from,id&$top=1000
I am seeing that the results are repeating, meaning the same message id keeps circling back (think its an infinitely) and the results take several seconds to return.
I am even able to reproduce that with Graph explorer. It doesn't seem to happen for other days in my inbox. I think I have come across some bug in the system but unclear what exactly it is.
Anyone know what it is?
This issue is now fixed. Can you pls try again?
Say, I use stripe subscriptions for my users with one plan which is $10 per month for 100 API requests and that's the standard price. However, if the user has used 150 API requests, I charge them $3 more on top on $10. For 200 and more requests it's total of $17.
Say, I've subscribed the user on October 9th. On November 9th they will be charged again by Stripe. When should I "freeze" the amount of the APIs the user has used during the month to calculate the overall price and start counting from zero again for the new period of November 9th - December 9th?
As far as I'm concerned, it's either on payment.success or invoice.success event in my stripe web hook controller. However, I think it's not reliable because:
Which one is it exactly - payment.success or invoice.success - the one I need? They occur both, as far as I know sometimes payment.success occurs first, sometimes - invoice.success and it's unknown which one occurs first in each particular case.
Theres's the time period between these 2 events, I don't know how long exactly, probably a few minutes. But during those few minutes the user might consume at least one Invoice
I'm not sure if it's guaranteed that for each user the events payment.success and invoice.success occur only once per month. Do they really? If not it's even less reliable to use them to achieve my goal.
invoice.created event occurs 1 hour before the Invoice is closed.
Um. Why wouldn't it be the moment your user clicked 'BUY'? The fact it took an hour/day for payment to be received isn't relevant is it? Think about iOS apps. I can buy the app right now, but most of the time I don't get an invoice from Apple for several days (even a week sometimes).
I think you're going to be frustrated trying to time it to events from your payment provider. IMHO that should be done within your app.
I'm using EWS SOAP service to fetch detailed free busy data from Exchange 2007. I'm trying to fetch data between 9am and 10:30am. The data returned is in intervals of 30 minutes so 3 slots are returned.
The first part of the response from Exchange contains the MergedFreeBusy string which shows 002, which equates FREE FREE BUSY. This would indicate that between 9am and 10am the room is busy and that between 10am and 10:30am the room is busy
However the detailed view returns two entries the first with a start time of 9am and end time at 10am and the busy type is incorrectly showing as busy. This contradicts the earlier mergedfreebusy data.
When i open Outlook and check the rooms actual availability i see that the room is free between 9-10am and busy between 10am and 10:30am. So the mergedfreebusy data content is correct while the detailed data is not. Why would this be happening?
Finally to set some more context, my timezone is GMT ( at the moment due to daylight savings its GMT+1, not sure if this should be an issue however because the response contains conflicting data).
One way i can work around this issue is to determine the bias from expected timezone that the user is requesting from. Other suggestions would be really appreciated.
I discovered that this is actually something which is covered in the MS EWS documentation. Enclosing URL in case anyone else runs into similiar problem - http://msdn.microsoft.com/en-us/library/bb655859%28v=EXCHG.80%29.aspx
I am storing in a database, every 30 minutes, Twitter's trending topics of a country Y. No problem with that.
Now, I want to get as much tweets as possible matching those trending topics for research purposes.
Since I would like to study the patterns of the trends, I would like continuous tweet data of at least 3 days centered in the day the trend peak was detected, for every trending topic. In order to achieve that, I thought of doing the following:
Suppose I am in day X. I could retrieve the unique trends of day X-2, and for every trend, look for tweets matching the trend in the interval [X-3, X-1], that is 3 days. However, the problem here is Twitter rate limitations. If I have 100 trending topics in day X-2, and I make 20 GET search requests/trend, I would end up doing a total of 2,000 requests, which overpasses Twitter's 350 hourly rate limit. If make 300 req/hour, it would take more than 6 hours to get the data for only one day...
Does anybody know any other (better) way for getting tweets associated with trends?
Thanks in advance
Twitter Streaming API?
Twitter Streaming API doesn't deliver any past tweets. You only receive tweets starting from the time the server connection is established. The search API will return tweets matching the current query up to 7 days old in theory, but that is entirely up to Twitter’s current load. (Note*-At times this interval has been as short as 24 hours. In addition, you are limited by the ability to only receive up to 1,500 tweets regardless of how old they are.)
Is there any way to get more tweets from the streaming?
None that I know. But, do refer the below mentioned information if you are considering to switch among search or streaming API.
Please choose your case:
If you need real time data and your number of requests are high:
Go for Streaming API
The streaming API requires that you keep the connection active. This requires a server process with an infinite loop, to get the latest tweets.
Advantage
1)Lag in retrieving results: Tweets delivered with this method are basically real-time, with a lag of a second or two at most between the time the tweet is posted and it is received from the API
2)Not rate limited.
If you need aggregate data regardless of its time range and your number of requests are not high:
Go for Search API
The search API is the easier of the two methods to implement but it is rate limited .Each request will return up to 100 tweets, and you can use a page parameter to request up to 15 pages, giving you a theoretical maximum of 1,500 tweets for a single query.
Advantage
1)Finding tweets in the past:The search API wins by default in this area, because the streaming API doesn’t deliver any past tweets
2)Easier to implement