Frequently Asked Questions

The plan I subscribed to has a limited amount of calls per API. How can I monitor my usage against that?

The numbers of requests, for different APIs, that your application has made are shown on your application page.

Click 'Apps' in the main menu and then click on your application. Under 'Subscribed Plans' you will see all plans your application is subscribed to. 

For each API contained in that plan you can see the usage compared to the rate limit of the plan.


When you add an application you are provided with a client ID and client secret for the application. You must supply the client ID when you call an API that requires you to identify your application by using a client ID, or a client ID and client secret.

To register an application click on Apps in the main menu and then click on the 'Register an application' link. Once you have provided an application name, description, etc you will be shown your application client ID and client secret.

Make a note of your client secret because it is only displayed once. You must supply the client secret when you call an API that requires you to identify your application by using a Client ID and Client secret.

I just want to use an API? What are plans?

A plan is collection of API resources or subsets of resources from one or more API. A plan can contain a mixture of HTTP GET, PUT, POST, and DELETE verbs from different APIs or it can contain all the GET verbs from various APIs. A plan can have a common rate limit for all the resources or each resource can have a different rate limit. Rate limits specify how many requests an application is allowed to make during a specified time interval.

Use this Developer Portal to browse the different plans that are available to you and select a plan that is most suitable for your requirements. Some plans have restricted access that you must request access to use. When you submit your request, the organization is notified, the API administrator assesses your request and they might contact you for more details. Other plans are available to use straight away.

Is it possible to test an API before signing up to a plan?

It is possible to test an API from this Developer Portal.

When looking at the details of an API you will see a table of the Resources contained in the API. This will show what method they are (GET, POST, PUT or DELETE) and what path the Resource uses.

If you click on the Resource you will see more information about it, what parameters it might take, what it returns, what possible return codes it might use and what they mean.

There is also a 'Try it out' button which enables you to try the Resource out direct from the Developer Portal.

If the API requires a client ID or a client secret for identification then you can specify these at the top of the 'API Resources' section.

Tip: For methods that have request body content you can click on the model schema on the right hand side to prepopulate the body field with the example content, then you can edit it as required.

How do I get an access token so my application can call your APIs?

When invoking an API from your application, you will need to pass along an access token. The access token can be obtained by making a couple API calls to Digi-Key's Authorization Server.  Please see our OAuth 2.0 documentation for more details.

I have forgotten my application client secret. How can I reset it?

Your application client secret is stored encrypted so we cannot retrieve the unencrypted version to tell you the value if you forget it.

You can reset it, which will update the stored value and return the new value to you.

To do that click 'Apps' in the main menu, click on the application in question and then you can click the 'Reset' link in the 'Client Secret' section.

Your new secret will be displayed at the top of the page.

Here is a simple pseudo code for OAuth2 and Digikey API example (given you already have a access token and refresh token).
        Function DigiKeyPartSearch(....)
           if (Current AccessToken is expired or close to expiring) then
               Get new AccessToken and RefreshToken from current RefreshToken
               // Might want to save the new tokens and ExpiredIn property.
           Call Digikey endpoint with AccessToken.
           If (Call to Digikey endpoint errors with (401) and expired AccessToken) then
               Get new AccessToken and RefreshToken from current RefreshToken
               // Might want to save the new tokens and ExpiredIn property.
               Call Digikey endpoint with AccessToken
               If (call fails) then
                     Handle error and check logs to see what problem is..
           Display PartSearch Response...

The proper way would be not to have to check “if the token is expired” before every call; this process should be offloaded to an OAuth thread. The thread will keep the token up-to-date and would be doing the token refresh. The main thread should only have to worry about the token if it ever gets a 401. If the main thread gets a 401, it will call the OAuth thread to get a new token.
As always there is the single threaded approach too, which will do a lot of blocking but I guess it will work.

The refresh token "expires_in" value is measured in seconds.


expires_in: 86399 

86399 seconds is ~24 hours

Your programmtic process for utlizing the refresh token should always check the "expires_in" value.  The "expires_in" time can change and is not static.

When using the developer portal testing tool, you will receive a 400 error when all fields for the header are not completed (this is a requirement of the tool)  :



Most likely this is do to the version of the TLS protocol being used.  Please make sure your application is using TLSv1.2.

When you received the error code 429, you will also find in the response header the field: "X-RateLimit-Reset"

This field gives the time, in seconds, until the rate limit is reset and you can begin making requests.



In the above response it would be 28,416 seconds (~8 hours), until you could make another request.

If you do not have the infrastructure setup to handle responses from Digi-Key, you can use the initial value of "https://localhost".

Sorry, we cannot provide programmatic assistance for security purposes as well as for legal reasons.  Thank you for your understanding of our policy on this topic.

Please feel free to use the contact form within the developer portal (here)


send an email to:

During the authorization process a password form is presented (url:, in this form you will use the credentials for your MyDigiKey account.

If you do not have a MyDigiKey account it can be created here:

An error code 400 is a Bad Request - Somehow your client request is malformed/invalid. Also possible, but less likely, the requested part has not been found.

An error code 401 is Unauthorized - Your access token may not be valid and may need to be refreshed. You have not subscribed your client application to a Digi-Key API plan.

An error code 405 is Method Not Allowed - You are making a request in a format that is not expected. Example is making a GET request when the data needs to be presented as POST.

An error code 429 is Too Many Requests - You have sent too many requests in a given period of time.

Digi-Key has found that the implementation of OAUth 2.0 is the simplest way to mutually be assured of a user's identity and the user's permitted access to our APIs. For the reason that sensitive information is exposed by our APIs, Digi-Key will only allow clients authenticated via OAuth 2.0 access.

Digi-Key will not permit access via permanent access tokens nor via any other equally less secure processes.

Please submit your request for an API approval by using:

the contact form on the developer portal (here)


by sending us an email at:

The Paths section of an API lists the operations available within that API. It can be colapsed to save space on the page. Click on Paths to colapse or expand the section. If it is still not visible try to refresh in a few minutes. Older versions of Internet Explorer may encounter problems viewing APIs.