0

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?

Darren Beale
  • 753
  • 1
  • 9
  • 24

3 Answers3

0

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.

DipakBoyed
  • 434
  • 2
  • 5
  • I've done as you suggest @DipakBoyed and the same problem occurs: `/api/v1.0/me/notes/pages?count=true&top=100&expand=parentNotebook,parentSection&filter=parentNotebook/id eq '{GUID}'%20and%20lastModifiedTime%20gt%202016-08-06T20:39:35.000Z` After 3 or 4 calls to the API this morning with this query I'm hitting the #429 again :( – Darren Beale Aug 07 '16 at 13:39
  • This is still a really problem for me. I can't do anything else. You keep blocking me on this request. All others are fine. – Darren Beale Aug 09 '16 at 09:48
  • Hi again! 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 problem now and are working on 1. a long-term fix as well as 2. a short-term workaround. If we come up with a reasonable short-term workaround, we will post again with more details. – DipakBoyed Aug 09 '16 at 20:39
  • Update on 2. short-term workaround: we've fiddled with our capacity and upped the throttling limits set by our partner indexing service while we work on the longer term fix. Hopefully this will result in fewer 429s for you going forward. – DipakBoyed Aug 09 '16 at 21:16
  • HI, just tried again: [xCorrelationId] => 23320071-a27d-4281-ad0f-369345b193a5 [statusCode] => 429 [reasonPhrase] => Too Many Requests – Darren Beale Aug 09 '16 at 21:21
  • Do you want to submit an answer for this and I'll accept it? – Darren Beale Aug 09 '16 at 21:29
  • sure submitting this as a new answer – DipakBoyed Aug 09 '16 at 22:00
  • btw the temporary increase in the throttling capacity will need a few hours to propagate through all the regions. – DipakBoyed Aug 09 '16 at 22:04
0

As a short term workaround, please try the following:

Instead of one query:

/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

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).

Perform this query for all the notebooks you're interested in:
/me/notes/pages?top=100&expand=parentNotebook,parentSection&filter=parentNotebook/id eq '{GUID}'
Jorge Aguirre
  • 2,787
  • 3
  • 20
  • 27
  • Thanks. I'm marking this as the answer as it does appear to solve my immediate problem. I've ran this a number of times in the last hour with no 429. Though I am still using the lastModifiedTime predicate too – Darren Beale Aug 10 '16 at 17:14
0

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)

DipakBoyed
  • 434
  • 2
  • 5