EVE Technology Lab

Transmission coded whilst listening to the most awesomest performance of the last century.

I've been doing some API work over the past week that should surface with Crucible 1.5 later this month. I thought I'd start off by introducing the changes as soon as possible so any interested parties could start making good use of them. I'll have Stillman come around to this topic and post about their availability on the testapi when they have been deployed there and basic testing has been passed. Why waste your time with my horrendously broken code, eh?

There are also some internal changes on the horizon for the API project. More on that below.


Feature Additions

Item Location API Added [Deployed]
/char/Locations.xml.aspx
/corp/Locations.xml.aspx

Both these call require a full legacy key or a CAK key with explicit permissions. Any call to them must be followed by the input variable ids which is a comma seperated list of itemIDs that must be owned by the key owner (supplied as characterID for the char call if the key is not bound to a single character). Furthermore, each and every ID passed in must be a valid location (possiblity to exist in space as a standalone item).

Call will return the items name (or its type name if no user defined name exists) as well as their x,y,z coordinates. Coordinates should all be 0 for valid locations located inside of stations. Crab people, crab people, look like people, taste like crab. This can thus be used to get your ship names, POS module names and coordinates (to group stuff.. yes, I finally lived up to my Fan Fest promise and can thus show my face on the next one!).

I cannot stress enough that supplying IDs that are not valid locations or do not belong to the supplied owner (wether explicitly supplied or implied from key) will result in a completely empty result set! I know this is less than user friendly but experience has shown anything else leads to constant scraping.

Cache timer on production services: 60 minutes.
A new access check box will appear on the support website for this call, dechecked for all existing keys of course.

Type Name API Added [Deployed]
/eve/typeName.xml.aspx

I noticed that the CharacterName call was no longer servicing typeIDs. So I added this call to do that for mobile apps that cannot ship with the type part of the SDE. Call signature is just like CharacterNames, requires no access and caches for all eternity as type names do not tend to change.

Corporation Member Tracking Changed [Deployed]
The access to this call for CAK keys has now been split between LIMITED and EXTENDED. All currently existing keys will be switched to LIMITED mode for security reasons. To request the extended view on a key that allows that an additionial parameter of extended=1 will have to be supplied.

This had to be done as all CAK corporation keys are director level keys and thus all CAK keys were exposing the sensitive part of the return set. This change does not affect legacy keys.


Defect Fixes

Confusing CharacterID call returns [Deployed]
When a character was renamed, and the CharacterID call queried with the new name the result set would most probably contain the old name paired with the characterID. This is somewhat confusing when you supply 100 names and get two ids back which do not match to any name in your list.

Now, the CharacterID and CharacterName apis will not return confusing result sets like this. They will also strive to realize when a name has changed and flush it from cache but that is only possible under specific circumstances so there is no guarantee of which name will be returned in the case of renamed characters. As a reminder we always flush the cache between major updates.

Confusing KillLogs error messages [Deployed]
Error messages in the Kill mail API were less informative than they should be. They have thus been changed to reflect the following:

1. Error code 119: Kill Logs only go a month back.
2. Error code 120: The expected killID, that has been returned, should be supplied rather than whatever was supplied.
3. Error Code 118: Refresh kill log with no killID supplied for most recent kills.
4. Error Code 119 and 120: Reminder that each application should have their private kill log key.

Confusing Journal and Transaction error messages [Deployed]
When passing in transactionIDs that the underlying transaction walker does not recognize, the code will do its best to approximate desired output and return that rather than just error. To high an ID will refresh the most recent transactions, too low will just use the oldest transactionID and a nonexistant one that fits between the preceeding two ranges will approximate to the closest transactionID in the walker.

Furthermore, asking for the single most recent transactions, and then requesting the two most recent transaction on the same walker will now return the two most recent transactions rather than crap out. Previously loading up a single record frontpage would demand that you pass in fromIDs to continue walking back in the transaction history.

All comments apply to both transaction and journal APIs.

CCP Stillman will come around to this topic and announce the new additions (and perhaps defect fixes) having been deployed to SISI and tested.

<3 <3 <3

Edit: had to post this, cause i forgot about the Like button!

Can we expect new API stuff that covers the POCOS and Planet interation stuff?
If the answer is yes, when can we expect it to hit SISI for trials?

Corps need this info:

• POCOs List -> location, taxes, standings…

Players need this info:

• Command Centers List -> location, number of structures in planet, POCOs taxes applied to us in each planet
• For each Command Center -> List of structures in each planet
• Information on each structure ->

1. Extractors: number of heads, program status (running/stopped), program length, expect end time of program and the summary information like the total resource yield and average yield
2. Industrial facilities: schematic in use, status (running/stopped)
3. Silos and Spaceports: contents stored, space available
4. Command centers: contents stored, space available, cpu and power usage…

Thanks, these are some great changes.

Could you add characterID/corporationID attribute or element to each char/corp call? I believe there is possibility of fringe cases like:
- user generate API key for character X
- insert it to application
- application requests APIKeyInfo for X
- user changes key to character Y
- application gets data for character Y, while assuming it's still X (because APIKeyInfo is still cached, or developer forgets to hammer APIKeyInfo on every cachedUntil)

would it be possible to add the stationID as "reason" in the wallet API for the refID 12 (Docking Fees)

http://wiki.eve-id.net/APIv2_Char_JournalEntries_XML
like the people could see where the isk comes from

I know you can do it.. .I trust in you ;)

if you're refereing to my post

it lets you see from what station the docking fees are coming

First few things are deployed to apitest. More to come today

I built my corp assets table with a container field (another itemID also located in the same table), and a locationID, Either a system or a station.

If location Is a system, and the location field is null, then I can pretty much assume it's something just floating in space.

On another note.

I cant seem to get any results other than



from the locations api.
My best guess here is that this has more to do with the fact the item doesn't exist on the test server, it being anchored in w-space and they aren't carried over to sisi...

That would work for anything actually in space but I was thinking about how to capture ships in stations as well since it seems they also can be retrieved. I figured people would like to grab them as well so they have the their names for them. I'll probably do like you did and start with anything that's not in a station but just thought I'd ask if someone had figured it out. There is also the issue of the stuff in cargo hold/ fittings etc also showing as in space I suppose that needs to be worked around in some cases.