Was octpart apikey invalidated?

[usk-johnny-s]

Hello everyone, It is my first post...

Yesterday I could get cost estimation by KiCost. But, Today kicost aborted by something.

I found error in debug log unfortunately.

Starting new HTTP connection (1): octopart.com:80
http://octopart.com:80 "GET /api/v3/parts/match?> queries=%5B%7B%22reference%22%3A+0%2C+%22mpn%22%3A+%22SN74LVC00APWR%22%7D%5D&apikey=96df69ba HTTP/1.1" 403 90

I tests errored query directly by curl , but it get error.

curl -G https://octopart.com/api/v3/parts/match -d queries="[{"reference":+0,+"mpn":+"SN74LVC00APWR"}]" -d apikey=96df69ba
{
"class": "ClientErrorResponse",
"message": "Forbidden request"
}

Then I tests that I sign up octpart for get my apikey, and access by curl with my apikey.
It works correctly.

I patch KiCost that replace hardcoded apikey to my apikey in "def query(query):" at "kicost/distributors/dist_octopart.py". it works correctly.

I think hardcoded apikey of octpart was invalidated.

[andresmanelli]

Same here, thanks for the workaround @usk-johnny-s !

[hildogjr]

I didn't check this. But maybe we will have to create the structure to save the different users token, as proposed in #295.

@usk-jonhy-s, just changing the api key makes KiCost works? Is this issue happening on the current code branch here in Git or just in the official release? The current key is not working at any time? (I have suspicious about the use of different users in different countries accessing at same time).

[hildogjr]

It is important the #314 http code response implementation and warnings to help debug and the users to understand this.

[usk-johnny-s]

I installed by "Easy_install kicost” few weeks ago, it's version 1.0.3.
At I revert my patch, original apikey is not works. I try 5 times but not works any time.

I read octopart website, then I found some limitation to use.

1. At https://octopart.com/api/legal , it without charge up to certain limits subject to the Terms of Use, written in "2.1 Usage Fees.".

2. At https://octopart.com/api/terms , it must display “Powered by Octopart”, written in "Additional Terms".

3. At https://octopart.com/api/docs/v3/overview , it can not exceed 3 HTTP requests/second per IP address, written in "Rate Limit".

I hope KiCost to require no additional fee for hobbyist.

[hildogjr]

Confirmed here.
@xesscorp, @devbisme, @mmmaisel this is a high priority issue.

It have also to be implemented the HTTP codes responses to give the correct warning in this cases
https://octopart.com/api/docs/v3/overview
not just a generic code error in Python.

We also need to achieve the usage terms (I have added some information and logos please, check it).

[hildogjr]

To people that use the GUI, in configuration there is a filed to save your key. But you still have to register at www.octopart.com by your self.

[hildogjr]

Even my personal KEY registered on 2018-10-30 have the status "Inactive pending Octopart approval".

[nickoe]

@hildogjr even if I regiested for an API key at octopart, and it has that status it still does not work it seems.

I get the exception:

Octopart KEY invalid, registre one at "https://www.octopart.com".

[hildogjr]

I add this exception to last release, to the user kwons. But appear that noone is able to do KiCost+Octopart API work.

Maybe, we will have to implement the individual distributors (mouser, digikey, ...) API. In the current status of the team, this could leave the KiCost users without it for long time.

We need some workaround. And join efforces to the others APIs.

@debisme, are you having the same problem?

[xesscorp]

I just tried version 0.1.47 and all I got was "TypeError: 'NoneType' object is not interable" on every test example I tried.

This was the problem I pointed out long ago about using Octopart: if they decide to stop working, then everything stops working.

Somebody should contact Octopart and ask why their stuff no longer works with KiCost.

As for using the individual distributor APIs, I have zero interest in being involved in that.

[xesscorp]

Well, I contacted Octopart today. Here is the main result:

Hi Dave,

Thank you for the prompt reply, and for providing more information about your use of the Octopart API.

Based on your historical volume of HTTP requests, you would likely need to set up at the 2nd tier >>>($100/month up to 12,000 HTTP Requests). However, this can always be adjusted later should you need >a higher or lower number of HTTP Requests.

Let me know how you would like to proceed and if you have any questions.

Best,
Ryne

So this would seem to end our short-lived love affair with Octopart.

[marcos-paltatech]

Is it possible to make it easier for each user to use its own key to access octopart API?

[hildogjr]

@marcos-paltatech, for now (this code here in Git but not officially released) I create a field in the GUI to the user fill with it own KEY (this will be save and restored with the GUIDE).
At the CLI, I still thinking in one way that is not modify the dist_octopart.py file or create a --octopart_key argument in the call, because this will force the user to type the key every time.

[marcos-paltatech]

Sounds great, thanks!

[marcos-paltatech]

Well, octopart did not want to provide me with an API key, even when it was for personal usage.

[hildogjr]

My key is broken as well and I used as academic research and developer here, never commercial. This is a big impact on KiCost. We leave the scrape method because it was begging impossible to maintenance and now this...
One possible solution could be the directly implementation of any distributor (digikey, mouser, ...) API. But this have to be studied first.

[mdeweerd]

Hi
Would it be ok for you that I look for sponsorship(s) from prototype manufacturers so that they contribute to the payment of the fee and in counterpart they would be clearly mentionned in the output of the tool?
The API key should itself be kept a secret somehow in order to avoid abuse by other users.
It also seems usefull to set up a proxy server that would handle kicost requests and act as a rate limiter.
The proxy could also accept higher rates from users that get a kicost API token from the prototype manufacturer in which case only that prototype manufacturer would be mentioned in the output.
Based on usage statistics, the monetary contribution from the manufacturers could be increased or their tokens would be more rate limited than others by the proxy...

I can contact at least three PCBA manufacturers in Europe, and even a few more that I do not work with.

[hildogjr]

Would it be ok for you that I look for sponsorship(s) from prototype manufacturers so that they contribute to the payment of the fee and in counterpart they would be clearly mentionned in the output of the tool?

I don't have option about and I think is better @xesscorp/@devbisme decide this kind of questions. I am just the main collaboration and programmer but not the original author of the tool.

The API key should itself be kept a secret somehow in order to avoid abuse by other users.

The only way is each user have it own key. It could not be available with the KiCost code.

It also seems usefull to set up a proxy server that would handle kicost requests and act as a rate limiter.
The proxy could also accept higher rates from users that get a kicost API token from the prototype manufacturer in which case only that prototype manufacturer would be mentioned in the output.
Based on usage statistics, the monetary contribution from the manufacturers could be increased or their tokens would be more rate limited than others by the proxy...

I am not a web programmer, I have not experience with this.
In this way, because KiCost is original made for KiCad, Digikey could provide us a better support with them API. (But this implicate in a different API-file to access each distributor, not use Octopart as a hub).

[anderwm]

They had also disabled my key, I contacted them and got this response.

Me:

Ok, so your terms don't provide a way for me to use the API personally? I would like to continue to use the Octopart API myself with my private key with less than 50 http requests per month.

Them:

For private use, you are permitted under our terms.
I will go ahead and reactivate your key. -- Please do not provide access to your key publicly without discussing with us in advance.
Thank you,
Ryne

[mdeweerd]

I also had exchanges with Octopart but they did not reactivate my key.

[xesscorp]

I'll contact Octopart and see what their policy is regarding personal licenses and KiCost. If they'll allow those, then we can go that way and make sure we don't provide a global key in the KiCost distribution.

I don't have any interest in creating a web service for handlingKiCost requests, whether this is tied to a prototype manufacturer or uses the distributor APIs directly. That's just too much boring work without pay. Others are free to fork KiCost and do what they want.

[dalamon]

Hi,
Looking for alternatives of Octopart and ECIA auth, I've found this one: https://www.oemsecrets.com/
But I can't find terms nor fees. Has anybody of you worked with it?
Thanks!

[xesscorp]

I'm talking with Octopart about allowing individuals to get their own API keys to use with KiCost. If that falls through, we can take a look at oemsecrets.

[Uberflup]

Likewise ended up having a conversation with Ryne concluding in receiving their pricing tier breakdown. Would be very keen to be able to use KiCost, to the point of happily paying for the service, but their min tier of $50/month for 5k requests would far exceed my needs.
Hoping for conversations/negotiations between @xesscorp and Octopart to be successful soon. KiCost would make my life a lot easier.

[xesscorp]

Were you going to use KiCost in a hobbyist or corporate role? Octopart seems to give out API keys for personal use (at least, they used to). Our problems really started when I released KiCost with my API code in it and everybody hammered their servers so they asked for $100/month. If you were using KiCost as a low-volume hobbyist, it would be telling if they wouldn't give you a key.

[hildogjr]

I am using my personal hobbyist key now and works successful.

[anderwm]

It seems they don't really understand that it is an open source tool with disparate users that aren't related in any way. What they should do is integrate the code here so that you could upload an xml file and get a BOM on their site. That would allow them to get revenue for the clicks.

In any event I am still using this code quite successfully with the very few requests I need.

[metropt]

I tried to get a validated API Key without success :(

[xesscorp]

Did you just request a key but they didn't activate it?

[metropt]

Yes, I sent an email saying that it is only for personal usage some dozens of requests per month and they answer this: "Per our Terms of Use, free access is offered only for individuals using the API for educational purposes, with a valid .edu or other university email address."

[xesscorp]

Thanks for that information. I'll go to my contact and see if that's their official stance for all new license requests. If so, it's pretty much going to end KiCost use unless we can find a way to get everyone a .edu email.

[metropt]

:)

[xesscorp]

Ha ha, wow! Probably shouldn't have posted that publicly. Octopart is probably watching.

[xesscorp]

I just got word back from my contact at Octopart: they are no longer offering free access to their API unless you are a student.

Based on that, I see two options:

1. Create individual interfaces to the various distributor APIs (Digikey, Mouser, etc).
2. Depending upon the pricing Octopart is charging for API access, we might modify the code to minimize the number of API calls so that people could still use it with minimal cost.

As for option #1, I have no desire to keep working on this and trying to handle all the differences between various distributor APIs. If somebody else is interested, then they can do it.

For option #2, I think any charges at all will massively decrease the number of people using KiCost, so it would probably be best to freeze it and let people use it at their own risk. I don't want to be getting problem reports from people who are angry that they are paying API access fees but KiCost is not doing exactly what they want.

[hildogjr]

Agree with the two observations, @xesscorp.
As far the code is, I kept it in the way that is possible (with some changes in kicost.py) add new dist_digikey.py, dist_mouser.py ... to distributors folder. Keep the KEYs / token will be easy in the GUI, but quite a problem in the CLI mode. Unless the user fill manually the lines at the code.

[hildogjr]

Moving on at #346