Hey there. Running my application that was working just yesterday now errors out since the assets endpoint returns a 404 error. I tried looking for dev blogs/ESI diffs, etc, but couldn’t find any place where this change was discussed or documented.
Anyone having similar issues? Is there a new endpoint I should use instead (that somehow doesn’t appear on EVE Swagger Interface?
Thanks.
They’re just broken at the moment. I’d try again later.
I have the same issue. don’t work for assets. Industry_jobs query works fine.
This error occurs in GESI (interface with Google sheets) and JEveAssets.
I cannot see that route in the OpenAPI spec here https://esi.evetech.net/latest/swagger.json
That would explain the 404 response.
ESI issues go here Issues · esi/esi-issues · GitHub and SSO issues go here Issues · ccpgames/sso-issues · GitHub but generally it seems to be a waste of time using the Github issue trackers for Eve. It’s more of a PR landing page to tick off the “We’re opensource” checkbox.
Also don’t hope for a notice about upcoming changes on any public API from CCP, they even broke their own example code when they pushed out a “non breaking” change to their JWT and broke everybody elses code too in the process.
If you want an alert on API changes you can simply run a diff locally of the OpenAPI spec or compare against a stored hash of the previous check and schedule it daily push out a notification.
That is 100% not why they did that. They did that because the people who made ESI, back in the day, had the idea that ESI should be community driven, so opening up the issues for everyone to comment on made sense at the time. It turned out CCP didn’t want to commit the amount of development time required to make that a reality, so, now it’s just a wasteland. but, it had nothing to do with CCP wanting to fake being open source, it was just an open issue tracker.
My guess it’s not going to be fixed until Monday, due to requiring a deployment and/or the ESI team and I’m 98% sure it’s related to the glue patch: Add Ice Hold location flag by maxsond · Pull Request #29 · esi/eve-glue · GitHub either being buggy or not applied in time. But, my guesses and statistics are wrong about 73% of the time, so…
Go to https://editor.swagger.io/ and have it load up https://esi.evetech.net/latest/swagger.json
You won’t find the endpoint there. It was removed from the API specification. You saying it was a case of “whoops something modified our API definition on a weekend?”.
Not responding to an endpoint route is one thing, having it go missing in action from the specification definition is a whole different ball game. That is a development change.
The endpoints are offline, so they’re are removed from the specs. automatically. That is how it have always worked, this have happened before, it isn’t the first time. I see no reason why you would question me on this, but, if you do, you should good look for the ESI dev blogs that explains how it works…
Perhaps because that’s gawd awful as we generate client stubs based on the OpenAPI spec. We don’t write clients by hand for API’s we generate them.
I would prefer a static JSON specification (build time) and accept an HTTP response to a failed route call rather than one generated from their router at runtime.
Imagine a developer trying to generate a client stub on a day that this JSON spec is “modified”, how would they know that they have a complete spec or not? That’s the problem with a “dynamic” specification. How do we know which days to generate a client stub for developing an application and which day not to?
EVE Swagger Interface this even says nothing about it, so much for the “status” API for the API.
“Provides a general health indicator per route and method” No it doesn’t. It doesn’t show this missing route as “red” so we cannot even rely on the meta get_status route for checking the API!
@Golden_Gnu Thanks for the input, was concerned perhaps it was just gone, forever. The fact it has happened before is both, reassuring and… /s absolutely shocking 
In any case my error checking performs well \o/
Their ESI router is generating the API specification at runtime from smaller route specifications, if one route is down then it won’t be able to combine them into the overall specification by the looks of it.
That is an absolutely terrible way to publish an API specification imo.
They need to publish their full specification from build time not runtime for app developers.
By having it published at runtime, we are also now unable to reliabily check it for development changes ourselves from a hash or diff.
It’s not “magic”, it’s a “tombola”.
They even have a status API that doesn’t indicate that the routes are not combined into the spec.
A status API (meta get_status route) is the right way to show status is down, not by pulling it from a specification and they can’t even get that right.
I guess I won’t be building that client stub today whilst the API specification is “partial”.
To be fair it a fair amount of time since it have happened last. But, it happened pretty often when they were making ESI. New endpoints would dropping regularly, due to crashing. Things are a million time more stable now and all endpoints will automatically restart if they crash, but, it won’t help if they just crash again as soon as they get back up…
API status route https://esi.evetech.net/status.json?version=latest
The routes that are down should surely show here as "status": "red" but they are not.
How can one even check the status on a dashboard or notify if they are not showing as red?
To see this in PowerShell (pwsh) you can do the following to get it in a table format
PS> Invoke-WebRequest https://esi.evetech.net/status.json?version=latest | ConvertFrom-Json | Format-Table
or
PS> Invoke-RestMethod https://esi.evetech.net/status.json?version=latest | Format-Table
This even works on Linux if you have .Net PowerShell installed, if you want the equivilent in bash you can use curl to query and jq to reshape the output.
It would have less moving parts if they didn’t combine and regenerate the OpenAPI spec everytime the routes restarted, so faster and perhaps more stable as a benefit along with providing developers with a stable readable spec.
Looks like it’s being worked on now
PS> Invoke-RestMethod https://esi.evetech.net/status.json?version=latest |Format-Table |grep -i assets
endpoint method route status tags
-------- ------ ----- ------ ----
esi-assets get /characters/{character_id}/assets/ yellow {Assets}
esi-assets post /characters/{character_id}/assets/locations/ green {Assets}
esi-assets post /characters/{character_id}/assets/names/ yellow {Assets}
esi-assets get /corporations/{corporation_id}/assets/ yellow {Assets}
esi-assets post /corporations/{corporation_id}/assets/locations/ yellow {Assets}
esi-assets post /corporations/{corporation_id}/assets/names/ green {Assets}
I think it has gone again. Is there anywhere to get status updates when it is being actively worked on?
Do devs have any view of this thread to know they are causing disruption or that has broken again?
Well the meta get_status route should be a way to get route status.
esi-assets endpoint has disappeared again, disappeared both from the OpenAPI spec and from the get_status route (lol).
Compounding the problem of being down, when it goes down, it blackholes everything related to it so we cannot even monitor the status of it and also blocked from development if we happen to be generating a stub at that time.
In PowerShell you can do the following (I am using Linux powershell so grep is easy to use, typically on PowerShell one filters objects using Where-Object and strings using Select-String cmdlets).
PS> Invoke-RestMethod https://esi.evetech.net/status.json?version=latest |Format-Table |grep -i assets
Meta routes are here EVE Swagger Interface
It’s green again.
PS> Invoke-RestMethod https://esi.evetech.net/status.json?version=latest |Format-Table |grep -i assets
esi-assets get /characters/{character_id}/assets/ green {Assets}
esi-assets post /characters/{character_id}/assets/locations/ green {Assets}
esi-assets post /characters/{character_id}/assets/names/ green {Assets}
esi-assets get /corporations/{corporation_id}/assets/ green {Assets}
esi-assets post /corporations/{corporation_id}/assets/locations/ green {Assets}
esi-assets post /corporations/{corporation_id}/assets/names/ green {Assets}
Bunch of endpoints missing again, corp contracts, assets, character assets…