API for creating, accepting contracts and sending ISK

Yes, EVE has a lot of 3rd party apps that make use of the available EVE APIs.

No, I don’t think EVE should go the way where external apps have input for the game.

Currently all of the EVE APIs are GET, not POST, if you get what I mean. You can gather all kinds of information and present them in any way in apps to help players.

What the APIs cannot do is allow an external app to do ingame actions such as flying a ship, or creating contracts. And neither should it, as automation in a competitive game like EVE is not progression, it is a degradation of gameplay where regular players will be at a disadvantage against people with the right (botting) software. Automated input is not allowed for a good reason.

It does. It’s even in the swagger description. The stupidity is to claim that something that is in the spec does not exist, just because you don’t want to see it.

The 4 UI paths are post.
Also the private message, route, and I believe others.

Ah you are right.

Still, in general sense the EVE APIs allow gathering of information, not gameplay input. That’s what I meant with GET vs POST.

Changing UI, sending messages and setting an ingame route may be POST methods, but these won’t affect the game in a way that it gives you an advantage over other players, unlike the ability to create contracts or update market orders for example.

POST and GET have no other semantic than “post a resource” or “get a resource”. The API is agnostic of the underlying effects. (And also in the case of ESI it does not respect that since the POST methods have no server effect)
For example the “search” path is post, while it has no effect on the server besides lag or making ESI crash.

What I mean here, is that referring to the http method is not a valid argument wrt what the API allows.

But I think you are right, in that the API does not allow to take an action that would alone allow to acquire anything. You can eg list the contracts, find the interesting one, but you need to be connected in order to show it and accept it. Same for route, it does not make you warp to the gate.

1 Like

Go try it.

You can see for yourself that there is not an ESI delay. In fact, I’ll go record it and post the video here, because I actually do things like fleet commands to create wings and squads, etc. using the ESI and there is no universal delay on the ESI (ie. the API is not delayed by an hour, only some endpoints).

EDIT: Here’s a quick, no edit video showing no 1 hour delay. Anyone can go confirm it (as the video is a bit choppy with the way OBS recorded it). Amazing what knowledge actually playing the game provides:

Don’t forget to do it twice : fetch your assets once, update your assets in the game, and then fetch again the ESI until your assets modification is visible. The delay will be exactly one hour, unless someone else already fetched your assets (in that case the delay is average 30 min).

So yes, if you want to create several contracts, since the creation of a contract will modify your assets, the creation of the second contract can fail for average 30 min because it tries to contract an item that is already contracted. Precisely because of the delay.

You just proved you have no idea what you are talking about.

Watch the video and as above, just go do it.

Some endpoints have a delay, not all. So asking how someone is going to manage the 1 hour delay is stupid. There is no reason if CCP implement this feature (they won’t), that a delay would be the rule. Clearly it already isn’t the rule.

ALL waypoints that are get have a delay. For position it’s 5 s, for public character infos it’s 24H.

Nope. Your video only proves you are using my words out of context. Especially in that case I was talking about the assets path, not the fleet one - since fleet path is useless for contracting.

And I did not say that this is a rule. I said it already exists in the assets path, which is the one you would need to make contracts.

Creating a contract wouldn’t be a GET request (it would be a POST). Additionally, not all all GET method endpoints have a 1 hour delay (eg. go run some of the fleet endpoints that use a GET method).

So if CCP added this proposal, it would use a range of endpoints and methods and no 1 hour delay would be required.

Rather than write rubbish, just go do it. There is nothing special about a GET v a POST/PUT/DELETE/etc. that mandates a 1 hour delay, and already isn’t for the ESI.

Bullcrap. You don’t know what you are talking about (assuming by waypoint you are just using some incorrect translation and using waypoint instead of endpoint).

Not all endpoints that use a GET method have a 1 hour delay.

Go test it and you will see that you are wrong.

I don’t need to test it, it is written in the swagger.
You are just too idiot to realize what I am talking about.

it’s written in the fleet path :

https://esi.evetech.net/ui/#/Fleets/get_characters_character_id_fleet

This route is cached for up to 60 seconds

LOL. Yes, CCP always keep documentation current. Ignorance is bliss I guess. No better way to know than to actually do it and see that what you are writing is incorrect. No surprise there.

The swagger is auto generated from the path that are available, so yes it is always up to date.

In your case it’s complete stupidity, removing words from the context and especially their explanation just in order to show yourself as a smartass …

In that case the context is creating a contract, which would require the assets path in order to be used. Your useless opinion about fleet path is just unrelated.

No. Documentation for Swagger (OpenAPI) is defined in a JSON or XML file and it isn’t always updated.

Some tooling (eg. OpenAPI tools for .NET) can auto generate documentation from the code, with additional specification information drawn from comments in the code.

Not all tools provide that and even in those that do, the comments in the code need to be kept up to date for the information to be kept up to date (and frequently they aren’t).

So still no, there is no 1 hour API delay that applies to the ESI. Some endpoints have a delay and others don’t (including endpoints that use a GET method).

Unrelated.
I am talking about the swagger, not the documentation.
The swagger IS updated.

Nobody cares.

Which I did not claim. Learn to read a full post before even trying to understand it.
What you are making is dishonest cherry picking, AKA out of context quoting.

Yes, so am I. Swagger (now called OpenAPI) is a specification for how to form and document APIs.

There is no 1 hour delay to the API, only on some endpoints of the ESI have a delay, so the OP wouldn’t need to propose any way to deal with a 1 hour delay, since if CCP implemented this proposal, they just wouldn’t add any delay, because doing so would be pretty stupid and counter to what the OP is proposing (but CCP won’t implement it anyway).

Unrelated.
On the path required, there is a one hour delay.
Anything else is unrelated.

And who claimed such a thing ? Only you.

It’s the whole thing you asked the OP about. It’s central to this whole discussion, because it’s your incorrect claim that the API has a 1 hour delay.

LOL. The endpoints to support this proposal don’t exist in the public API.

Yes, what you wrote was:

My bad, to use different words for the same outcome. If you ask the OP how they are going to make a contract with an API that has a 1H delay, then I just reworded that, intending the same meaning.

But, the typical anal rubbish you go on with comes out as usual, so with that, good luck.

It’s not.
I did not claim the API has a whole one hour delay, you added that stupid claim.

I literally wrote that I was talking about the assets path. Here :

No, you are using it out of context, by removing the next sentence that explains the issue and specifically talks about the assets path, which IS delayed one hour.