API: GET price_history

hi Afols,

what you think about this suggestion:

GET Price_History (APIkey, BO_id, Condition, Color, Currency, DataRange) : ResultSet
GET Price_History (APIkey, design_id, Condition, Color, Currency, DataRange) : ResultSet

Condition (OptionList (All, New, Used) )
Color (OptionList (Colorlist) )
Currency (OptionList (List of Currency) )
DataRange (OptionList (Current, 6 Months, 1 Year, 2 Years) )

:ResultSet

total_lots :int
total_amount :double/float
total_value :double/float
average :double/float
maximum :double/float
minimum :double/float

Example:

GET Price_History (1234...., 961948, New, Black, EUR, Current) : ResultSet

:ResultSet

total_lots 115
total_amount 23,342
total_value 822.63
average 0.05
maximum 0.85
minimum 0.01

many regards

Matthias Wollenberg
FUM Store

Comments

  • 11 Comments sorted by Votes Date Added
  • edited January 2015 Vote Up0Vote Down
    I'm not familiar with your formatting, but I assume it would follow standard HTTP arguments for queries and JSON for replies (like the rest of the API). What you suggest seems straightforward.

    Personally, I would love if the API would also provide us with standard deviations along with the averages. This is a very important piece of information.

    I have code for that "other place" that downloads and parses complete price guide pages to compute standard deviations... but some of these pages weight 600kb, it's a big waste of bandwidth just to get a little number!
  • Also, unlike in the example above, we need more than two decimals for prices. Assuming USD as currency, 3 decimals is a minimum.
  • I would certainly find this useful and as Stragus says above, direct access to statistical totals would allow more efficient API calls for the majority of analysis. On BL, we filter just UK & European transactions to keep the returned datasets to a minimum, but they're still pretty hefty on the higher volume parts. It would be nice if we could filter price history data by store location on BO also.
  • BL has a 'Get Price Guide' call in their API. Does BO have something similar yet?
  • No, we don't make any of the price history available via the API at this point in time
  • as others also say, this is very helpfull, is there an important reason not to implement this in the api ?

    @mattwoll , maybe you could write something to read the page source and based on experssion filter out the data that you want to use?
  • I've been waiting for such a feature too ...
  • Hello community,

    sorry for my late reaction.

    @pwpeter
    i wrote my idea in a mix of Pseudo code and UML classdiagram.
    I hoped it could be a better explanation of my idea.
    If read our sentence right, you want an explanation of this pseudo code?

    @all
    I think, that API can be a powerful tool, and the BO API need a revisitation and a new version system.
    For the future, the API System of BO, symbols the whole funcionalty of BO. So is than easier, to develop Clients like apps, desktop-clients or an connection to an ERP System like SAP, MS Dynamic NAV, etc.. .

    kind regards

    mattwoll
    FUM Store

  • @matwoll Hello, thanks I think we mean the same thing just talking in 2 seperate ways.
    I totally agree with you.
  • Before we can seriously make our software connect to BO and put 250k of used parts up for sale, we'd like to be able to use our pricing routines based upon true historic BO sales data. BO could make these calls efficient by remembering the previously delivered sales history data per BO API consumer.
  • So, @Lawrence, even though we've not been introduced properly to eachother, my first request would be to make sales history available.

    Currently investigating what is needed to connect our software to BO.
This discussion has been closed.