I have a graph api that, to spare you details, updates a calendar with events and removes duplicates.
I have events from the source data that are be shown as existing when the code decides whether or not to add it.
If I run 'https://graph.microsoft.com/v1.0/users/somecal#someco/calendarView' with a date in the header, I get a response showing it exists. However, when I log into the calendar via Outlook, it is definitely not there.
This only seems to be affecting some items that are around 149 days out.
It updates about 250 days worth of data, with probably 1000 http requests per run.
Ahhh! When querying All Day events, be sure not to list the TIME in the date time format of the parameters!
Related
I am implementing a Zapier Integration's polling trigger. I have built a trigger and an API which serves the data correctly. However my concern is about: how to make sure that I provide the new data only, when zapier polls.
I know about the deduplication mechanism. I provide ids in all the items and Zapier makes sure that one item is used only once. However in my application the items can go into hundreds very quickly and in months they will be in thousands and beyond. I want an optimised solution where I serve only the items which will eventually be used by Zapier, thus reducing the memory usage in my application.
Some timestamp can be save for every call, which I can store inside my application but that will not be a foolproof solution. Same API can be used by user in multiple zaps, plus there are sample calls etc.
Great question! The simplest way to do this is to add a date parameter to your API that lets you filter for items created after that date.
Then, in your Zapier code, provide that param for all trigger calls. I'd set the time to 24 hours ago. So, when a trigger fires, it'll only get items created in the last 24 hours. That could be a big list, but items will cycle out after a day.
We are now getting an error within our Book A Room powerapp when trying to find available meeting times. The error has only started since we added a new room which takes us to 21 rooms in our Office 365. The error is as follows:
The issue seems to be that in the API request all 21 rooms are included in the requiredAttendees json attribute. Once I remove the newly added room on Office365 the error goes away.
All rooms in the catalogue need to be included in the request to see whether they are available for booking but is this limit of 20 a hard limit on the API side? If so, what alternatives do I have?
I'm not familiar with the Office365.FindMeetingTimes() endpoint, but if this is a limitation of the API, then it sounds like you may need to implement a sort of paging in your app. The first time the app calls FindMeetingTimes(), you'll have to pass in the first 20 rooms. Then if the user isn't satisfied with the proposed times, they can initiate a "find more times" feature that will call FindMeetingTimes() with the next 20 rooms. I'm not sure if this is the best solution, but it could be a workaround.
Is there a way to get ALL the responses for a single day in one transaction for a specific survey? on the API doc, I know there is the /surveys/{id}/responses/bulk option, and even I can send the start_created_at variable.
But I think that the API response has a max number of records/data it can send, it that case, what could the solution be? Paging through the results?
I'm using the .net API, found at this site, but I can build my own wrapper if necessary.
Reference link to API doc: /Surveys/SURVEY_ID/responses/bulk
Yes you're right the /surveys/{id}/responses/bulk endpoint is what you're looking for, and you can use the start_created_at and end_created_at to filter data to a date range.
The SurveyMonkey API doesn't allow a full dump of all your data, it will always be paginated. By default it'll paginate 50 at a time, but you can change that by using the per_page GET parameter.
That max per_page varies by endpoint, for responses BULK it is 100. So you'll have to fetch 100 at a time, looping through the pages to get all your data.
One alternative is to use webhooks and set up a subscriber, that way you can get new responses in real time and fetch them one by one. That way you can keep your data updated on your side as new responses come in, rather than running a script or endpoint to bulk dump all your data. But this depends on your use case, if you're building something like an export feature, then you'll have to go through the paginated route.
I have a Server which will be pulling some changes in the form of JSON Webservice and that data I will download in my iOS App.
That Thing is done but problem is with date
I have not given any date condition Neither in server side nor in my App
Whatever data will come from JSON webservice I will fetch in my app on starting of the app.
But I will also fetch the changes which I have already made.( Means previous day data or downloaded data)
Should I get the data for the today date from webserver? and IF i get the today date data then what If one missed the todays data.
Should I check from the App side that "Which data is been downloaded "
I am not sure how do I give the condition to getting checked the previous version and Where should the condition I should give ?
Web Server side or the APP side
Is the intent for the app to see the newest stuff when it updates? One approach is to pass a date on the request, which says "give me everything newer than this date". The app would then remember the newest item it receives and use that date to make the next request.
To handle a first time case -- when the app has no newest item yet -- one approach is to send no date on the request. The server would take this to mean "give me the newest items you have".
There's also the need to handle limits. What if there are too many new items to be practically returned? One idea is to return the limit, plus some indication that there are more. Then the app can request again starting with the date of the newest item received, and so on.
If gaps are okay in the app's copy of the data, you can handle the limit case by treating as the first time case... just return the limit number of newest items. If you do it this way, then the best first-time request would be to pass something like [NSDate distantPast]. So the server would always expect a date and always perform the same logic:
count items newer than the date passed on the request if there are
fewer than limit, fetch and return them if there are more than
limit, fetch and return limit items
Since today (July 5th 2012) Facebook changed the return value for events from a unix timestamp to a string. This messed up my iOS app that displays concert dates.
I grab the event data from the event fql table.
When i look at the json i get back from Facebook, i now see a string like this:
"2012-10-07T19:30:00+0200".
Now, if the event creator did not post a start time for the event on facebook, the api just returns "2012-10-06" - with no time attached, and it returns the event one day to early.
While the facebook page in the browser displays the event date correctly, the api returns the date one day too early.
What is going on here, am i missing something and what is the right way to handle this?
From yesterday everything went back to unix format, i checked and found out that this kind of string ("2012-10-07T19:30:00+0200") was a bug! only some apps were receiving that and in fact the graph api explorer never used it and always used unix time...Thank you facebook, now i have to change everything for the second time in one week.
Here's the bug link:
https://developers.facebook.com/bugs/415058451869226?browse=search_5001222c9ff516a78134883