Search the Community

Showing results for tags 'external ids'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Rebrickable
    • News
    • Suggestions
    • Help!
    • Bugs
    • API
    • Mobile App - Rebrickable LEGO Shopper
  • Inventories and Data
    • Set Inventories
    • MOC Discussions
    • Other Data
  • Other Stuff
    • LEGO News, Events, Community
    • Non LEGO
  • Projects

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Bricksafe URL



Favourite Set(s)

Found 2 results

  1. Hi, over at the LDraw forums, there is a discussion going on about using the Rebrickable API to create a cross-system part mapping reference file. I've knocked a script together which queries the Rebrickable API for the parts and then renders it as an XML file partially akin to LEGO's LDD ldraw.xml file. One of the questions that has come up as a result of processing the data is with regard to a single Rebrickable part being mapped to multiple part ids in an external system (e.g. LDraw, BrickLink, ...), such as seen here. The question is can any meaning be placed on the order in which the external part ids are listed? For example, is the first part which is listed always going to be a more recently generated part, or is the order in which they are listed when there are multiple part ids random? Regards, David
  2. I have alot of parts in my inventory for which I have the bricklink-IDs (written on paper :-) ). As an example let's take 4592c02, which, when entered in the search-box on V3, leads me to: This page clearly states the bricklink ID correctly. Now I want to do the same over API: entering the bricklink-ID and calling an API-function which returns me the correct Rebrickable-ID (298c02 in the example) and a list of external IDs. I tried /api/v3/lego/parts/ with the search-parameter also, but I cannot find any API-function which returns me the external IDs like it was returned by the V2-function get_part and parameter inc_ext=1. In V2 I could use the Bricklink-ID in the part_id of get_part and it returned me the rebrickable_part_ids, if the part_id was a non Rebrickable-ID. I think there are different solutions: Use the search-parameter of /api/v3/lego/parts and extend the result with the external IDs (like in V2); part_ids in the result are clearly Rebrickable-IDs and it is up to the consuming client to evaluate the result; in conjunction with that extend also the result of GET /api/v3/lego/parts/{part_num} so that it contains the external IDs (like it does for print, molds and alternates) Make /api/v3/lego/parts/{part_num} also react on Bricklink-IDs (and maybe others like ldraw, brickowl,...) and have an external-array in the result (this is pretty much the same behaviour like in V2) Add extra-functions like /api/v3/lego/bricklinkparts/{part_num} (and the same for maybe LDRAW, BrickOwl, LEGO (designid)), which return at least the Rebrickable-ID of the part Alternative 2 would suite best to my needs (not much change in my use of the API). From an architectural point of view, 3 would be the best solution (clear separation of concerns). 1 makes sense at all to me (search should search for "everything" (like search on the site) :-) ) Everthing said is just IMHO.. :-) Best regards Dietmar