You may have noticed in the client when viewing a killmail there was a new option called Copy External Kill Link.

First of all:
i've been asking for this since years, for example on fanfest,
so a big and honest:
Thank you CCP FoxFour, for making our (3rdparty) world a bit brighter.




since i believe not everyone will know what you mean by the new option, here a SC that should help people find it: Screenshot

basically its the context menu you can open by clicking at the box to the top left of your killmail.

That's cool. Any chance for multiple select in the kill reports window and a way of copying multiple external URLs at once to the clipboard? Newline separated of course.

FoxFour is definately the best Furry Dev

I... you... just no. No no no. Best dev, great. Furry dev? When have you ever seen me wear anything furry? CCP Nullarbor however... https://twitter.com/CCP_Nullarbor/status/367084848869310464

I noticed the links to solarsystem and corp and alliance objects unfortunately they don't work. Care to comment?

PS. I've had the fortune of attending the pub crawl with tiger suited and somewhat drunk Nullabor and can confirm it was wild.

I am also aware of an issue where some KMs are returning: application/vnd.ccp.eve.UnsupportedMediaTypeError-v1+json

So far I have tracked this to Sleepers, if you are getting this on a killmail without sleepers let me know. :)

I... you... just no. No no no. Best dev, great. Furry dev? When have you ever seen me wear anything furry? CCP Nullarbor however... https://twitter.com/CCP_Nullarbor/status/367084848869310464

Hey guys,

You may have noticed in the client when viewing a killmail there was a new option called Copy External Kill Link. Well as of today that link is now live and good to go: When you click on it you should have something like this copied to your clipboard: http://public-crest.eveonline.com/killmails/30290604/787fb3714062f1700560d4a83ce32c67640b1797/

The idea behind this endpoint is that it takes a killmail ID and a hash of the killmail and if the hash is right for that killmail ID we return a response with the contents of the killmail. Assuming killboards build in support for it this means you can API verify a killmail without having to give out your API details.

If you run into any problems with this endpoint please let me know here.

Enjoy guys! :D

It's rather annoying that the bizarre CCP MIME type means it doesn't open in my browser that has a JSON viewer. Why doesn't it just use application/json like everything else?

Other things:

Why doesn't it send faction = null when someone's not in FW like the regular killmail API does?
Why does it send every number twice, once in int form and once in str form?
Why are corp/alliance icon URLs contained in objects when their only data is the URL?

Please don't tell me this is a hacked-together JSON converter on top of MSSQL XML output.

Some (most) of the numbers blow the 32 bit boundary, putting them in string format makes them extractable by everything, not just those handling uint64 or 64 bit double.

In CREST fields can be optional, when something is null we just don't return it. Those fields are optional.

I cannot remember the exact technical reasons, but there was some reason for sometimes wanting a string representation. Something about JS not liking long numbers. I actually only put it in once, but CREST takes it and sends both the Long and String version.

If you don't return all fields, is there a list of all possible fields it can return? I don't have access to enough killmails on my personal account to possibly find every field.



If the problem is numbers that are too big for 32-bit, why not just send them only as strings instead of an integer format that may break applications when it gets too big and let the application worry about manipulating them?

Killmail:
killID - Long
killTime - String
SolarSystem - Reference
- id - Long
- name - String
moon - Reference - Optional
- id - Long
- name - String
victim - MediaType
attackerCount - Long
attackers - MediaType

KillmailVictim
character - Reference - Optional
- id - Long
- name - String
- icon - External Reference
corporation - Reference - Optional
- id - Long
- name - String
- icon - External Reference
alliance - Reference - Optional
- id - Long
- name - String
- icon - External Reference
faction - Reference - Optional
- id - Long
- name - String
- icon - External Reference
damageTaken - Long
shipType - Reference
- id - Long
- name - String
- icon - External Reference
items - MediaType - Optional

KillmailItems
itemType - Reference
- id - Long
- name - String
- icon - External Reference
quantityDropped - Long - Optional
quantityDestroyed - Long - Optional
singleton - Long
flag - Long
items - Array - Optional
- itemType - Reference
-- id - Long
-- name - String
-- icon - External Reference
- quantityDropped - Long - Optional
- quantityDestroyed - Long - Optional
- singleton - Long
- flag - Long

KillmailAttackers
character - Reference - Optional
- id - Long
- name - String
- icon - External Reference
corporation - Reference - Optional
- id - Long
- name - String
- icon - External Reference
alliance - Reference - Optional
- id - Long
- name - String
- icon - External Reference
faction - Reference - Optional
- id - Long
- name - String
- icon - External Reference
securityStatus - Float
finalBlow - Bool
damageDone - Long
shipType - Reference - Optional
- id - Long
- name - String
- icon - External Reference
weaponType- Reference - Optional
- id - Long
- name - String
- icon - External Reference

If the problem is numbers that are too big for 32-bit, why not just send them only as strings instead of an integer format that may break applications when it gets too big and let the application worry about manipulating them?

is this too replace the normal API killboards as they don't seem too work atm?

is this too replace the normal API killboards as they don't seem too work atm?

is this too replace the normal API killboards as they don't seem too work atm?

Just to be clear, I don't fully know or understand the decision for both string and none string representation of numbers in CREST. If you would like to talk about the design of CREST come to Fanfest and those that worked on it I am sure would love to talk your ears off.

For now though, lets keep this thread focused specifically on this endpoint.

There are currently 3 known issues with the endpoint:
1) If a killmail has types on it that were deleted in the past, for example the old probes, the endpoint would choke and die. /sad panda.
2) If there was a sleeper or other NPC on the killmail that belonged to a faction and not a corporation the endpoint would choke.
3) The image links for corporations, alliances, and factions did not work.

All three issues have been fixed and should hopefully be deployed during Thursdays downtime.

Issue 1 was a tricky fix because there are a few ways to fix it none of which are really that good. The chosen solution is to carry on as normal but replace the name of the item with "Invalid item".

Issue 2 was due to some NPCs not being in a corporation. When the killmail is generated in those cases their corporationID is populated with a factionID and the endpoint would choke when trying to match a factionID to a corporation. I now have some special casing in there to deal with this and if a corpID is actually a factionID put it into the faction slot as it should.

Issue 3 was really just me not testing well enough. Characters use .jpg and tested fine but corps, alliances, and factions all use .png but I clearly didn't test that and thought they would all be jpg. I was clearly wrong. This has been fixed.

Sorry for the brokens but hopefully that should clear up most of the problems. If you have any further issues after Thursday please let me know and I will see about fixing them ASAP.

The fixes were successful. zKillboard currently has over 10k crest endpoints in our database, of which just over 700 of them had errors prior to this release.

After the release, only 4 have errors, and 2 of those are invalid hashes.

Thanks FoxFour!

Just as an update, the most recent hotfix was deployed today and we seem to be good for the most part.

I was presented with a potential issue though: https://zkillboard.com/detail/36931325/

The NPC in there, which appears to just be a torpedo, has no corporation listed. I don't know why this would be happening after a quick look over the code but I will continue to dig and see if I can find out why.

If you have any other examples of issues or broken things with the CREST killmails endpoint please let me know. It has been a bit of a rough launch and I apologize for that but I am hoping we are through the worst of it now. Thank you for all your patience.

I was presented with a potential issue though: https://zkillboard.com/detail/36931325/

Just as an update, the most recent hotfix was deployed today and we seem to be good for the most part.

I was presented with a potential issue though: https://zkillboard.com/detail/36931325/

The NPC in there, which appears to just be a torpedo, has no corporation listed. I don't know why this would be happening after a quick look over the code but I will continue to dig and see if I can find out why.

If you have any other examples of issues or broken things with the CREST killmails endpoint please let me know. It has been a bit of a rough launch and I apologize for that but I am hoping we are through the worst of it now. Thank you for all your patience.

Some kills are just bad in game. Like one of the people on my Dread loss has no ship

*wonders about ban hammers and killboard links*

Not sure what you mean...

is there an easy way to get the crest api endpoint link from the old api killlog? would be cool to have ONE endpoint to get killmails for posting manually (via crest endpoint) and via old crappy api thingy

im not asking you to implement it because its bullshit to work on that old api anymore imo... ( or maybe its just a rly tiny change that takes only 5 mins :3 )

but afaik this is how the endpoint link is build:
http://public-crest.eveonline.com/killmails/kill-id/some-magic-hash/

we get the kill ID from the old api.... so thats no problem. but what about the hash? how is that generated? is there an easy way to generate the hash out of the information from the old API?

i like the fact that there are item names in the crest api... so i dont have to maintain a stupid item table in my DB \o/