Https://{character_id}/assets/ returning 404

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.

I for one would really like to see this working again, is there any hope of an update on this?

1 Like

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 and have it load up

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!

1 Like

@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 :astonished: :wink:
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.

Source: Introducing the ESI API - EVE: Developers

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

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 | ConvertFrom-Json | Format-Table


PS>  Invoke-RestMethod | 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 |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 |Format-Table |grep -i assets

Meta routes are here EVE Swagger Interface

It’s green again.

PS> Invoke-RestMethod |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…

Don’t worry, it’s a “million times more stable now” :smirk:

PS> Invoke-RestMethod |Format-Table|Measure-Object|Select-Object Count

This will tell you how many routes are up

million times more stable now

I see what you did there, good job! :smile:

I would suggest perhaps querying and storing the meta status route every 60 seconds (x-cached-seconds header is set to 60) and track it over a period of time for each endpoint/routes to see which is the most unstable when plotted on time vs route.

Seems to be gone again, no corp assets or character assets available, or shown to exist here EVE Swagger Interface