Terms of Use Clarification

[cptn....@gmail.com]

I am looking at the Octopart API again after having looked at it last year, and I am trying to understand the Terms of Use listed on the http://octopart.com/api/docs/v3/overview#tos page. I suspect some of this is legalese, though I suspect a couple of them are simply to make sure people pay you money (which I can understand). Still, I'd like to get clarification/explanation on a few of the points.

• You will not use the Octopart API on or in connection with any electronic component distributor website - What does this mean? Does this mean I can't use the API to get pricing data (or whatever data) and then go to a vendor web site to do the same thing?
  
• You will not use the Octopart API for purposes of bulk catalog-to-catalog comparison of pricing information between distributors - Isn't this one of the points of the API - to see pricing data so you can do a comparison? Your documentation says "Using the Octopart API, you can access stocking information, price breaks, lead times, minimum order quantities and much more information from over 100 stocking distributors including Digi-Key, Mouser, Newark, Premier Farnell, Arrow, RS Components, Future Electronics, Grainger and many others. All of our pricing and availability data is included by default in every API response". (bold is my emphasis) If you're not allowed to do a comparison then why provide information "from over 100 stocking distributors"?
• You will not maintain any cached data retrieved using the Octopart API for a period longer than 24 hours - Please clarify what "cached data" refers to. Does this mean that if one pulls down pricing information it can't be saved into, say, a database for use 3 months from now, as pricing is unlikely to change all that much in that time frame?
  

[Janine Yoong]

Hello! 

Sorry this language is so confusing.  Looks like we need to consider a rewrite. To boil it down in plain english - the data we provide comes from our component distributors partners and there are conditions associated with its use.  Here are responses point by point:

- you can't use the API if you are in the component distribution or sales business (or you're performing a service for a company in that business)

- you can't use the API to download whole catalogs to do price analysis for competitive reasons, related to the above (e.g. let's say you're trying to undercut certain suppliers and are pulling down thousands of parts at once to do price checks - can't do that~!)

- we're less concerned about the pricing data (which does, to our understanding, change somewhat frequently and requires updating) - this point is related to proprietary pieces of data like datasheets, images, reference designs that our content partners own.

Hope that helps! Please don't hesitate to ping us with more questions.  If it helps, we're happy to hear about your use case privately - you can email us at a...@octopart.com

Janine

--

---
You received this message because you are subscribed to the Google Groups "Octopart API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to octopart-api...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[cptn....@gmail.com]

OK, that makes things a little more clear. I'm still concerned about the third bullet, though. We're a small company that designs mostly RF power amplifiers, and we also provide design services. We're not a component distributor. We buy from component distributors like DigiKey, Mouser, etc. to make stuff.

I wrote an in-house application to manage our designs in terms of part definitions (i.e., internal part numbers and variants, indicating different manufacturers for that kind of part, like a 10 kOhm, 1/4 Watt, 2% resistor) and BOMs. Included with the part definition is also purchasing information records so that we can get rough pricing for a design in various quantities (so we know what a fair price is for the thing we make for our customers). This purchasing information provides details like who you can buy it from, their minimum order quantity, how it's sold (individually, box, tape & reel, etc), and the price breakdown (per 100 pieces, per 1000 pieces, per 10000 pieces, etc). This purchasing information is saved in our SQL server database along with all the part definitions and BOMs. What I was looking to do was add a feature that would update this pricing information just so it's kept up to date.

What I'm concerned about is whether doing this would run afoul of the third bullet in that list. I know that one can also use the API to upload a BOM, and I'd also like to do this, but I'm considering this a separate feature, not necessarily a replacement operation since you would not have pricing information for some of the items that show up in our BOMs (like mechanics). Thus, this feature would likely be limited to getting a costed BOM for, say, a PCB rather than the full design.

Thanks for your help.

[Janine Yoong]

Thanks for the detail.  This use of the API sounds like precisely what we (and our distributor partners) would like to support.  Working on a feature that keeps pricing updated is exactly keeping with the spirit of third bullet.   (I understand what you mean by it being a separate feature since we don't list mechanical parts.). 

Please do continue using us!  We'd love to hear more about your work and if we can be useful in more ways. 

Janine