I was contacted by someone at Arrow Electronics about adding them to KiCost as a source for part pricing info (like Digikey, Mouser, and Newark). They have an API for fetching that data, but it requires a key to access. So anyone who wants the Arrow pricing data would have to get a key from Arrow (which they said they would provide).
My question: would anyone use this feature if it requires 1) getting a unique key from Arrow (and providing whatever contact info they require) and 2) installing the key into KiCost (a one-time procedure for each machine running KiCost).
II think the most important is: if they support you then you should add it 
Yes, I agree. But I doubt they have any thought of paying money to do this. Which means I’ll only bother with it if enough KiCad users really want it. At this point, it seems they don’t.
Yeah, a lot of reads, but no raised hands
Personally I think they should get rid of their key shenanigans and go with the times.
They want to sell stuff to end users and should make that as pain free as possible.
If anyone overloads their API by bombarding their system with too many requests and thus renders it unusable for anyone else they got the wrong programmer for the job really.
I would appreciate and use this feature.
Arrow has access keys because their pricing is specific to you (if you register parts with them). They will actually contact the manufacturer and get preferred pricing based on your estimated annual usage. Further more you can continue to negotiate pricing with the reps. Once you have an account with them you can login and see your pricing vs. what’s available online (without part registration).
I can understand their reasons from a business perspective. And they’re actually better than Digikey who actively denied my access to their API. And Mouser has an API but it’s restricted so it only provides two, low-quantity price breaks for any part query. That’s why I had to resort to web scraping. But I really don’t want to bother figuring out another web scrape for Arrow, so I thought I’d see if people would use the API if it required registration and personalized keys. So far it looks like “no”.
Thanks for the input. I guess that’s one “yes”.
Open software can grow if “everybody” who needs a function at one time adds it and then others can just use it an maybe add another function.
The more functions a SW has, the more inteIrest and the more potential for extra Idevelopment.
It appears that you “need” it, so I’ld say “go ahead”.
[I’ve contributed here and there myself, this is my approach].
I’ve use(d) kicost, but hack it to not query any external distributors. Extracting the metadata from a KiCad schematic and putting it in a spreadsheet is the most useful feature. Hacking it so that it outputs a format that can then be uploaded to Octopart is where I find the value.
It takes like 30-90 seconds to run kicost with external look-ups on 50+ line items, just to find out I screwed up a field in my schematic and to repeat the entire process.
Any thoughts on adding a simplified output version compatible with octopart?
The offline version could leverage octopart’s many existing API look-ups.
If you want to extract metadata, then maybe kifield is the utility you want to use. It pulls the component field data from the schematic into a CSV file and can also inject the CSV file back into the schematic (which kicost can’t do).
I’ve posted before about the drawbacks of using Octopart. However, maybe scraping the Octopart page (rather than using their metered API) is a way to speed the online part lookup. Someday I’ll look into that.
1 Like
If you want to extract metadata, then maybe kifield is the utility you want to use. It pulls the component field data from the schematic into a CSV file and can also inject the CSV file back into the schematic (which kicost can’t do).
At first glance it looks awesome. Thanks for the heads-up and the hard work!