Third Party Developer Blog


December 2014 third-party developer update

CCP FoxFour | 2014-12-09 15:20 | Comments


Attribute Enhancers

Back in this dev blog we announced a change to the way the API returns implants. We also announced that the attributeEnhancers element was being deprecated  and would be removed come December. The actual message returned in the API said December 1st. The code has now been submitted to remove this element and will be deployed on December 9th with Rhea.

Clone Grades

First let’s talk about some small changes to the XML API for Rhea on December 9th. With the removal of clone grades in Rhea, the char/CharacterSheet endpoint contains a few elements that are now irrelevant. They are as follows:

<cloneName>Clone Grade Alpha</cloneName>

As with the change to implants in the character sheet in this dev blog, we will be assuming consumers of the API cannot handle elements they expect being there suddenly disapearing. For that reason the above is what will now be returned for all characters. We could have set cloneSkillPoints to something absurd such as 500m, but then people might not notice their application is still checking it. By setting cloneSkillPoints to 0 any application that checks it and compares to your current number of SP to see if the clone is out of date will always say you have an insufficient clone. On top of that, I am really looking forward to all instances of EVEMon alerting people that their clones are insufficient in Rhea. That will bring me great entertainment.

An update to the developers site was required with the release of market data in CREST and the requirement for applications wishing to handle that data being authenticated. The new version of the devlopers site, which you are reading this blog on, lets you create the authentication only applications you can already create and also CREST applications. When you select “create a CREST application” you will get some new fancy options that let you select what scopes you would like your application to have access to.

For now the only available scope is publicData, but it's a start and the list will grow in time. So go now and create your publicData applications.



So, public CREST. Let’s have a brief chat about it shall we? Right now it is available on both HTTP and HTTPS. I want to make this a formal notice that the HTTP, the non-SSL version, will be going away. Still figuring out the exact date for killing it off, but no sooner than March. If you have any objections to this idea please voice them now.

New Resources

Some new resources have been added and exposed to public CREST for information on the types in EVE. ItemCategories, ItemGroups, and ItemTypes are all available now from the root of the API for both public CREST and authed CREST. For now ItemType only includes the name and description of a type, but in time the hope is that other information such as Dogma will be included.


I want to stress once again the importance of watching for and adhering to the X-Deprecated header in CREST. If you are not sure what I mean about this please see this video here. The whole video is full of great information but I have linked to the section that talks about the X-Deprecated header.

In the next while some CREST resources will be marked for deprecation and it would be wonderful if your libraries and applications handled that gracefully. If you are looking for some resources to test your application or library on with the X-Deprecated header please see the application/vnd.ccp.eve.Api-v2+json representation of

Static Data Export

The Static Data Export will receive a small update this release as well consisting of two small, but fairly important additions.

Those of you who work with the dogma data, especially fitting tools, you will be happy to know that the dogma expressions table is now included in the SDE. The exclusion of this table was mostly just an oversight, but has not been a huge issue as its use case is pretty limited and those of you who do use it got the data from the client cache. We really don't want you to have to do that though and so are working on getting it included in the SDE. You can find it now in the SDE as a table called dgmExpressions.

The second change is to the dogma effects (dgmEffects) table. There will be a new column called modiferInfo added. This is most important now for the new Amarr Tech 3 destroyer, the Confessor. This is a new way for us to author dogma on types and generally an improvement overall for us. You can expect to see more things using this method going forward. The kicker however is that a type may have a dogma effect that uses the older dogma expressions and new ones with the modiferInfo. If the effect has modifierInfo that takes precedence and the other information is ignored. Fun times ahead!

You can download the new version of the SDE, which includes the above changes, from this page:


Default Client Settings

When we launched the SSO publicly for everyone and let you go about creating your own clients for it we changed some default settings. Mainly this was setting it so that authentication only applications would not get refresh tokens and had an expiry time of 5 minutes. We are removing those changes so that authentication only applications and CREST applications will both get refresh tokens and have an expiry time of 20 minutes. The refresh tokens have an unlimited lifetime.

I feel I should also point out that there is a page on the community site that allows you to revoke an applications access:

We have heard from some people that users are often not sure what the SSO is and sometimes think websites are trying to steal their passwords. We are also working on a page to clearly explain to users what the SSO is, how to revoke access, and those kinds of things.

The changes to default client settings should hopefully be going live next week. I will make a quick post once they have gone live to let you all know.

Defining Who Can Sign-in

Right now if you use the SSO in your application people with banned or inactive accounts cannot sign-in. This is a pretty big disincentive to use the SSO. So we are changing it. Once the change goes live there will be no restriction on who can sign into your site via the SSO. On a related note we are looking into the restriction that you must have an active EVE account to create applications on the developers site. The restriction on having paid us money in the past will stay, but we want to remove the active account restriction there. Third-party developers do amazing things and we want to support you in every way possible.

As with the default client setting changes, we are not 100% positive on the deployment date so we will let you know once they are deployed.

Final Notes

There is a fair bit of stuff in this dev blog. As always I will be watching the comments and answering any questions I can. This will probably be the last dev blog this year though so I wanted to go over a few final things.

While things have been moving fairly fast the last 6 or 8 months of this year in terms of tools and resources for third-party developers things are going to slow down for a bit. First of course there is Christmas coming up and with it some vacation time. At the beginning of next year however I will also be focusing on some internal stuff. The NGINX configs for CREST and public CREST need to be completely rewritten along with some other infrastructure for CREST needing some updates. That work will probably take longer than I want but is required to help ensure the best performance of CREST and that we can continue marching forward. That's just the start though as there is a pile of other technical debt I want to take a chunk out of early next year. 

So while you will probably notice development of things for third-party developers slows a bit, I want you all to know it's for a good reason and in the long run will be really good for everyone.

That's it for now, thanks for reading space people.

CCP FoxFour