EVE Technology Lab

Hello,

I am currently working on a website which is heavily reliant on the contract API. During some API calls I've noticed a strange response with respect to items which happen to be blueprints or singleton. The row attribute values of the XML document (ContractItems.xml.aspx) do not match the API documentation and are in my opinion wrong.

As the documentation (http://wiki.eve-id.net/APIv2_Char_ContractItems_XML) points out, a negative value for "quantity" is in fact a code. If the item does not happen to be a blueprint, a negative value of "-1" should imply a singleton. If the item happens to be a blueprint, a negative "quantity" of "-1" would be an original, whereas "-2" would be a copy.

Please look at this screenshots:
Contract.png
Api.jpg

This are screenshots of an active contract I've set up for testing purposes as well as the returned XML file from the API call. It contains a "Cap Booster 800 Blueprint (Copy)" and a "Scourge Heavy Missile Blueprint (Original)". According to the documentation, I expect the values in the XML file for the copy to be "-2" for "quantity" and "1" for "singleton", as a copy is not stackable. I also expect the values for the original to be "-1" for "quantity" and "1" for "singleton", as the blueprint ist researched and thus also not stackable. I'd also expect the attribute "rawQuantity" to show up.

All "quantitys" are positiv, which implies that non of the items are blueprints or singleton, which is wrong. Also the value of the attribute "singleton" is "0" for every row and there is no "rawQuantity" attribute.

I can not see how I could determine whether the current item is a blueprint copy , original or whether the item is a singleton within the returned XML file.

Does anyone else have this same problem?



Best Regards,
Nexuscrawler

I've already done that.
I was told to make this post to further track down the people with the same problem and maybe what's causing it.
But if the problem is already known....

If you don't use the contract API for your projects then of course, why care about it?

But as it is for me, when people know about this bug, they can pretty much trick my system as I have no way to check whether the player gave me (for example) an actual carrier BPO or just a BPC.
Both are represented the same way on the API page.