Partkeepr: Octoparts question

So we can understand what you are proposing - how is the 500 part request/month measured? We don't host anything so each person is running their own server.

Hi Bret,

Part request are counted when a part is returned from a query. Each user
would have to apply for their own API key on Octopart.com so the limits
would be a per user basis.

Do you feel like this would be enough to bring value to PartKeepr's
hobbiest users? To be honest, aside from the Demo instance I have not used
PartKeepr.

Any insight would be greatly appreciated!

On Thu, May 21, 2020 at 9:14 PM bret watson notifications@github.com
wrote:

So we can understand what you are proposing - how is the 500 part
request/month measured? We don't host anything so each person is running
their own server.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/partkeepr/PartKeepr/issues/1125#issuecomment-632424718,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APVO4KPUSHS7MXHRTHQLA23RSXGWDANCNFSM4NHL37GQ
.

Forgive my ignorance since I don't use Octopart.. but the request - is that a stock query, a product search, or an order?

@baradhili Long story short: They condense various information about parts so that users can download these information like seller data, datasheets, device parameters, etc. Very nice to import parts quickly into PartKeepr.
It is very valuable if you import more than a dozen parts a time.

@JamesOctopart I can tell you my personal thoughts on it. This is not an official PartKeepr statement.
I am on a similar route as @aarontc in https://github.com/partkeepr/PartKeepr/issues/1030#issuecomment-632406313. When you start importing new parts into the database you quickly import more than a few a day. You can go into the 1000s within one weekend easily when doing an inventory of your basement. On the other hand, this is not something I do on a regular daily basis. So maybe only a longer horizon with a multitude of requests might be sufficient (not 500 parts/month but 1500 parts/3months).
For those need to import more parts, it should be possible to increase the level by paying in a one-time-fashion. Something like I buy 2000 extra accesses that are used after my monthly budget is empty.

One more note: I am talking about the number of imported parts, not of API access times. A single search if a part is in the database, then selecting all the relevant parts of the import and all the downloads create a multitude of API accesses. If you are thinking of 500 such accesses, this is most probably too low. But I have not looked into the details of the API here.

I would be very interested in this as I relied on Octopart to drive my KiCad2PartKeepr project.

https://github.com/Gasman2014/KC2PK

For my personal projects a level of 500 parts would be of interest. Has the API changed much? Ensuring that an app works well with an API requires testing and so some flexibility for Open-source developers without buying a subscription would be welcome.

Whats about Collection some statistics by api key on your server? Maybe its a good idea to give some keys to people who ask for them as hobbyists and then count their average usage.

I doubt that you will find a reasomnable average of users to calculate the required API calls but at least it is a way to go.

As I was thinking about my setup of PartKeepr I would find it reasonable if a hobbyist get one month unlimited test and later a few hundred requests per month. In my case I will use some thousend calls in initial setup the inventory, but later there are not that many parts added.

I would love to get the free parts/month quota for OctoPart. It is so convenient to get the data for your parts.
Yes, initially you probably require more than the 500, but inserting 500 components still is quite some work to do (ok, it doesn't take a month).

So, yes please!

I believe this is just a publicity stunt. I have sent various emails asking about the possibility of having free api access in the future and have received no answer at all.

Ola PTDreamer, you're the stm32 soldering iron guy! Still did not finish mine for a JBC iron.

I asked a similar thing to SnapEDA and they replied me 2 months later (last week). Let's hope they are more lenient towards us.

I got a reply from Octopart next working day confirming that they were planning on offering a free tier 'in a few weeks'. This was at the beginning of June. Fingers still crossed!

On 2 Jul 2020, at 13:35, Martijn Kuipers notifications@github.com wrote:

Ola PTDreamer, you're the stm32 soldering iron guy! Still did not finish mine for a JBC iron.

I asked a similar thing to SnapEDA and they replied me 2 months later (last week). Let's hope they are more lenient towards us.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/partkeepr/PartKeepr/issues/1125#issuecomment-652979341, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACADFOKBXDWBKPB2CL3U273RZR5I3ANCNFSM4NHL37GQ.

IDK, I emailed them a few weeks back. They acted like they never heard of Partkeepr.... maybe that's how they found the project?

My query wasn’t specifically about PartKeepr - I also used to use Octopart for my BOM ordering application - which uses the PartKeepr database as a backend. (Kicad2Partkeepr) but have not been able to use it since they removed API access.

https://github.com/Gasman2014/KC2PK https://github.com/Gasman2014/KC2PK

On 2 Jul 2020, at 16:23, Michael Fisher notifications@github.com wrote:

IDK, I emailed them a few weeks back. They acted like they never heard of Partkeepr.... maybe that's how they found the project?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/partkeepr/PartKeepr/issues/1125#issuecomment-653071390, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACADFOOBDRUB3YDZBCRQYCTRZSQ6LANCNFSM4NHL37GQ.

First, I have to say that I did not reverse engineer the protocol that PK uses regarding Octopart. So every statement here is just my educated guess.

Be careful with the API request number. I am unsure, how many requests PK is starting for a single search of a part. It might be the case that each download (datasheet, image, ...) is a unique API call. The same holds true for distributors' data and the like.
This would cause a single search to cost at least 10 API requests! That means after 50 parts/month you reached the limit.

Is someone was willing to check this, it would help us all. Unfortunately, I do not have the time at the moment to work my way through.

Btw: I asked at Octopart as well. They told me the following:

The current API does not provide free access at this time. I understand your concerns and I apologize for the inconvenience. However, I am happy to mention that Octopart is launching a new version that will have the infrastructure for a free tier, hopefully by the end of this summer.

We hope to see you sign up when API v4 is launched. Please let me know if you have any questions.

I want to stress that due to the lack in development power we might not be able to use the mentioned API v4 of Octopart.

At the beginning of this year, my Octopart registration was rejected as my use case (Partkeeper as hobbyist) was not compatible with Octopart's terms of use.
These terms specifically mention you can not download and store data (like datasheets) on your own system and all data retrieved from Octopart can only be cached for maximum 24 hours. (https://octopart.com/api/terms)
This means you will have to make use of the API all the time and with a hard limit, I don't want my projects to come to a stop when I reach the API call limit.

For PartKeepr in general, I would be more interested in having the ability to integrate other APIs besides Octopart.
Most parts distributors provide APIs to their customers for retrieval of datasheets and pricing information.
It is not a single aggregated source of data, but that means it is also not a single point of failure or bottleneck.

Hey all,

Updating this thread as we have launched the new GraphQL API which we're
pretty excited about and can be found here: https://octopart.com/api

A few updates:

Our free tier allows for 500 parts returned per month with the ability to
purchase more if needed.

There will be some work needed to be done to ensure PK can query our new
API, our getting started guide can be found here:
https://octopart.com/api/v4/getting-started.

If concerned about the part limit in the free tier, I would recommend using
multi_match with limit 1 to ensure each match only returns one part.

We hope the new features in our API will be valuable to the PK community,
just let me know if you have any questions, you can email me directly at
[email protected]

-James

On Thu, Jul 2, 2020 at 12:04 PM Christian notifications@github.com wrote:

First, I have to say that I did not reverse engineer the protocol that PK
uses regarding Octopart. So every statement here is just my educated guess.

Be careful with the API request number. I am unsure, how many requests PK
is starting for a single search of a part. It might be the case that each
download (datasheet, image, ...) is a unique API call. The same holds true
for distributors' data and the like.
This would cause a single search to cost at least 10 API requests! That
means after 50 parts/month you reached the limit.

Is someone was willing to check this, it would help us all. Unfortunately,

I do not have the time at the moment to work my way through.

Btw: I asked at Octopart as well. They told me the following:

The current API does not provide free access at this time. I understand
your concerns and I apologize for the inconvenience. However, I am happy to
mention that Octopart is launching a new version that will have the
infrastructure for a free tier, hopefully by the end of this summer.

We hope to see you sign up when API v4 is launched. Please let me know if
you have any questions.

I want to stress that due to the lack in development power we might not be
able to use the mentioned API v4 of Octopart.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/partkeepr/PartKeepr/issues/1125#issuecomment-653094570,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APVO4KJABPVCMTJQSICYJXTRZSVYRANCNFSM4NHL37GQ
.