EVE Technology Lab

When I make calls to /corp/Locations.xml.aspx and /corp/StarbaseDetail.xml.aspx with a properly permissioned corp API key, approximately 4 out of every 1000 calls executed to those endpoints fail with error code 221 ('Illegal page request! Please verify the access granted by the key you are using!'). The errors are sporadic, and do not have any correlation with any specific arguments passed to the calls. I am using an API key that I control and have not touched the permissions for, so I am confident I have permission with that key.

Furthermore, these errors are set to be cacheable for a full day rather than being transient with <1h allowed before retry according to the response, causing my POS management application to grind to a halt for an entire day unless I manually blow away my cache like a bad citizen and reissue the query before the 1 day expiration is up. If I do that, the call immediately succeeds and returns the correct result.

I am using the EVELink library, which I also am a maintainer of -- the library does properly utilize caching, and respects the expiry/cache lengths returned by the EVE API.

I believe there may be an intermittent fault between the API servers and the datastore maintaining information on API key permissions. The easy fix that would make my life infinitely easier is simply to make the Error Code 221 condition only be cacheable for 15 minutes rather than for an entire day, and should require no additional debugging.

However, a 0.4% error rate is still non-ideal.

I reported this months ago and it's continuing to be a problem, seems to have got worse recently. On mobile so tricky to find my previous post.

Affects many endpoints not just the ones OP mentioned.

Yes - I'm not saying it's limited to those endpoints, but those endpoints get called 10-20+ times per run of my app whereas I only hit the other endpoints once, so the chance of a failure on those endpoints cumulatively over time is much higher than on other endpoints that I call less often.

I do not know when it started, but it's been happening for the entire two weeks I've been working on this application, which is the first application I've written against the API that needs to repeatedly poll to fetch info on dozens of objects anchored in space (and thus increased the chance of seeing the error).

Can't say this is a good idea but hey :D In SeAT there is some grace logic that will retry again for a few times and eventually 'give up' and ban the broken call.

I can concur with the OP though that the 221 error occurs very sporadically. It is especially bad on the endpoints listed above however I have experienced this on other calls too for which nothing has changed on the keys as well. As far as debugging goes, the only thing that really helped has been the 'try again later', which is why people would probably resort to things like ignoring the explicit requirement for cachedUntil.

If you make the Error 221 not cache for 24h and instead only cache for somewhere between 5 and 15 minutes, that would solve the problem in the OP.

Good to hear that Stevie is doing the job we hoped many of us hoped he'd do when voting for him ;)

It would certainly greatly improve the situation in lieu of a fix to the underlying problem.