Question posted in 
I tried to engage with the API team via Twitter but I’ve not had a response and development is grinding to a halt here…
In short I keep getting a 429 when developing against the OneNote API, I know that this suggests I’m hitting the API too hard, but I’m not.
At worst I’m doing maybe 1 or 2 requests per minute, manually invoked by me as I develop. Sometimes I’ll leave it 10-15 minutes between calls, sometimes this works, sometimes not.
I’ve been working on a particular problem the last few days.
In my code I make a call to get all notebooks, sections & section groups in a single query (filtered to only return data from certain notebooks)
I then make a second call to get all updated pages for those notebooks. I’ve been fiddling with the filter string to get this second call working (which I now think I have), but 9 times out of 10 I get the 429 on this second API call.
Is there some way of getting my user account whitelisted please?
FWIW this is my second query (the spaces normally get encoded):
/me/notes/pages?count=true&top=100&expand=parentNotebook,parentSection
&filter=(parentNotebook/id eq '{GUID}' or parentNotebook/id eq '{GUID}' or parentNotebook/id eq '{GUID}') and lastModifiedTime gt 2016-08-05T11:34:09.000Z
This does work as I’d expect, the date clause is working now, but I can only test very occasionally as I get the 429.
Incidentally if I run my second filter through the API console I get a 504 “Proxy request timeout”, every time. This has been since I’ve added the parenthesis around the notebook predicate.
So I’m pretty much unable to continue development, how do I resolve this please?
3
Answers
Just a hunch: can you try splitting the second call (for getting updated pages) into separate http requests (one for each notebook id)?
Also if what you want are update notifications, webhooks might be the better way to go.
Lastly apologies for the silence on Twitter.
As a short term workaround, please try the following:
Instead of one query:
Remove the “count=true” (are you using this?) and leave only one parentNotebookId filter. The results will be by default ordered by LastModifiedTime descending (most recent first).
Unfortunately you’re hitting a bad bug in our GET Pages API (when called with filters and additional query params). Effectively, we are doing a crappy job of applying the filters when calling our indexing service (which in turn is throttling us). We’ve identified this as an on-going problem which starts throttling callers especially under heavy load.
Short-term workaround: we’re fiddling with our capacity and upp-ing the throttling limits set by our partner indexing service temporarily while we work on the longer term fix. Hopefully this will result in fewer 429s for you going forward.
As a future-proof resolution, I would also encourage you to look into @Jorge’s suggested answer. (remove the count=true query param and filter only on 1 parentNotebookId (no lastModifiedTime filtering)