Direct answer
DigiKey chip stock monitoring should use the complete manufacturer part number (MPN) with the Product Information API, then retain timestamped inventory, price, and lead-time evidence. Successful authentication does not mean every part is visible. Permissions, market, rate limits, and network failures must remain distinct from OUT_OF_STOCK.
Who this is for
This guide is for engineering, purchasing, and supply-chain teams that need to review whether a DigiKey part can be bought, how quantity pricing changes, and whether lead time is moving out. It describes monitoring and evidence, not a DigiKey supply guarantee. Actual operation in Chip Monitor still depends on an administrator enabling the channel and providing a healthy API credential.
Why the exact MPN matters
LM358DR, LM358D, and different packaging suffixes can be separate catalog records. A monitor should store the complete MPN, manufacturer, market, and request context instead of turning a broad keyword search into one stock record. Confirm package, temperature grade, packaging, and environmental suffixes before importing a BOM.
Use the Chip Monitor inventory workspace to keep the supplier MPN as the identity key. An internal BOM or SKU can remain a note, but it should not replace the supplier part number used for the API request.
What the DigiKey API can usually tell you
| Signal | Monitoring use | Boundary |
|---|---|---|
| Available quantity | See whether a sellable quantity is returned | Always read it with market and timestamp |
| Price breaks | Compare unit cost at requested quantities | Currency, account, and quantity can change it |
| Lead time or estimated availability | Detect a longer replenishment window | It is not a delivery promise |
| Manufacturer, package, description | Verify product identity | It does not replace engineering review |
The API only returns fields exposed for the current application, market, and request. A missing price is not zero stock, and a stale price should never be presented as a current quote.
How one check works
- Normalize the complete MPN and choose the intended market and currency.
- Use an approved OAuth application to obtain a server-side access token; never log or expose it in the browser.
- Request Product Details and verify that manufacturer and MPN match the target.
- Record inventory, price, lead time, source, response time, and upstream status.
- Update stock state and alert baselines only when the result is parseable and identity-verified.
This ordering prevents a 401, 429, timeout, or parser change from being written as zero inventory. Failed attempts remain diagnostic events until a valid observation arrives.
Reading status and failures
- In stock: a recent, identity-verified response includes a positive quantity.
- Out of stock: DigiKey explicitly reports zero or not sellable; review lead time with it.
- Unknown or collection failed: evidence is insufficient, often because of 401/403, expired tokens, 429, timeouts, or a field change.
- Stale: the last successful observation is outside the configured freshness window.
For repeated 401s, inspect application approval and token scope. For 429s, reduce cadence and follow the published limit. A timeout for one part should not turn an entire batch into stockouts.
Planning rate limits and cadence
DigiKey documentation distinguishes the standard Product Information budget from a separately approved higher budget. The commonly documented standard is 120 requests per minute and 1,000 per day; an approved product may have 10,000 per day. Account response headers and the applicable agreement are authoritative, so these figures are planning references rather than guarantees.
Confirm the transport and credential state on the DigiKey integration page before choosing a cadence. Do not spend the full budget on retries. Exponential backoff and a channel pause are safer than doubling requests after every failure.
What happens when the API fails
An official API and a public web path are separate DigiKey transports. Chip Monitor does not silently scrape a web page after an API error because authentication, fields, and evidence boundaries differ. A web path is used only when an administrator explicitly enables that independent transport.
Troubleshoot in this order: verify MPN identity, inspect the last successful time, check token scope, confirm market and currency, then inspect network and rate limiting. Validate one part after a fix before resuming a large rule set.
Frequently asked questions
Why is a part missing after OAuth succeeds?
OAuth proves authentication, not catalog permission, market selection, or product scope. Validate request parameters and returned identity; permission failures should remain errors rather than stockouts.
Does a price change mean inventory changed?
No. Price breaks, currency, and requested quantity can change independently. Keep price and inventory alert rules separate.
Can one API request monitor many parts?
Batch support depends on the endpoint and account. Chip Monitor keeps explicit target records and validates each MPN even when an upstream request can contain multiple items, so one malformed response cannot overwrite a batch.
Evidence boundary
This article is based on DigiKey developer documentation and Chip Monitor's current transport contract. Fields, quotas, authorization, and commercial availability can change. lastReviewedAt is the editorial review date, not a supply commitment. Recheck the official product information before making a purchasing decision.
Start with one exact part on the DigiKey integration page and then expand the rule from the inventory monitoring home page.