Pulse
Josh Chambers
Aug 20, 2026
Previous article
Custom Overmolded Cables in Weeks, Not Months
James Sweetlove
The Nexar API, Explained: What it is, how it works, and what it changes for the people who use it
First, what an API is
API stands for application programming interface. A person uses a website by clicking and reading. A program cannot click, so it needs a service window to ask a precise question and get a precise answer in a format it understands. That window is the API. Octopart is a website where our users can look up an electronic component and view it from every angle. This view includes who has the component in stock, its cost, lifecycle status, technical attributes, and more. You can even search for a component to see which other components are similar to it. The Nexar API delivers the same information directly into your company’s business software systems.
Benefits of using the Nexar API
- Integration into your own tools: You can embed up-to-date data from the Nexar API directly into internal systems, such as a custom Purchase Order Management system or a Product Lifecycle Management system.
- More than supply data: Alongside supply information, the Nexar API also retrieves design data from your Altium 365 workspaces, so a single integration can pull sourcing and design data together.
- Consistency across teams: Everyone using the same query gets the same values back: the same price, the same inventory level, and the same units from the same moment in time. Numbers stay comparable across people, across reports, and over time.
- Automation at scale: The Nexar API lets you programmatically query up to 100 parts at a time and run up to 300 queries per minute (potentially analyze 30,000 parts in a single minute!)
The Nexar API
The Nexar API primarily consists of:
Supply data is Octopart's part information: the supply side of the API provides access to over 95+ million parts, with stock, pricing, lifecycle status, lead time, datasheets, technical attributes, CAD models, and similar part suggestions, taken from electronic distributors and updated daily.
Design data is for Altium customers, covering the contents of your design workspaces from projects and component details. The Nexar Data Model is publicly valuable here: Nexar Voyager. In the data model, each operation carries a prefix telling you what it touches: sup for supply, des for design, and adm for account administration.
Example 1: you describe the answer you want
Nexar uses GraphQL, a query language for APIs. With other API infrastructures, you request a fixed block of data, receive all of it, and write code to discard what you did not want. With GraphQL, you write out the shape of the answer, and that shape is what comes back. Here is the documented form of a search by MPN (manufacturer part number):
query MpnSearch {
supSearchMpn {
results { part { id name mpn } }
}
}
Read out loud: run a search over manufacturer part numbers, tell me how many hits there were, and for each result give me the part’s identifier, name, and MPN. Nothing else comes back. Ask for more, and you get more. In a live Altium demonstration, searching an RA0E2 microcontroller from the Renesas RA family returned the part; adding technical specifications confirmed it was flagged as compliant with RoHS (restriction of hazardous substances); adding the datasheet returned a link to the file, its name, and its creation date, because Octopart scores the available datasheets and can hand back the best one. None of it arrived until it was asked for.
Example 2: multiple ways to search
Similar to Octopart, the Nexar API is flexible in how you can search for a component. If you’d like to perform a broad search, you can search for a partial MPN or search based on keywords. If you know precisely what you want, then you can search for the exact MPN.
For the broader search, the operation you want to utilize in the API is ‘supSearch’. This operation will perform a fuzzy match search.
query search {
supSearch (q: "Current sensor") {
hits
results {
part {
id
name
shortDescription
}
}
}
}
In the above example, the search for “current sensor” would return the number of hits, the IDs of the parts, the names, and a short description of the component.
'The supMultiMatch operation takes a list, up to 100 parts, identified by MPN or by SKU (stock keeping unit), and resolves them together. Unlike ‘supSearch’, when you utilize ‘SupMultiMatch’ all partial matches are ignored. This one asks about two components:
query MultiSearch {
supMultiMatch (queries: [
{mpn: "SY55855VKG", limit: 1},
{mpn: "BAV99-7-F"},
]) { hits parts { id name mpn } }
}
Each entry can be one line of a BOM (bill of materials), so a whole bill gets priced without anyone opening a browser.
Example 3: the design side and writing data back
Design works the same way. Operations prefixed des, such as ‘desWorkspaces,’ reach into your Altium 365 workspaces. Because the data is shaped like a graph, you follow relationships outward from wherever you start: from a workspace to the designs inside it, and from a design to what it holds, which ranges from nets and component details through to MCAD (mechanical computer-aided design) and positional information. You choose how far to travel and how much of each stop to bring home.
Reading is only half of it. A mutation writes: adding a comment, uploading a project. Where an operation needs a file, you post it to the Nexar file service first, at files.nexar.com/File/Upload, passing a token that carries the design.domain, user.access, and openid scopes. What comes back is an identifier, valid for 24 hours if unused, that you reference in the request itself. Treat that identifier as opaque, because its format is subject to change.
What this changes in your work
The value is easiest to see by looking at how three roles already spend their time and at which part of that time the API gives back.
The procurement manager or buyer
At an EMS (electronics manufacturing services provider) or an OEM (original equipment manufacturer), this person confirms that every part in a build is in stock, finds a distributor who can meet the delivery date, understands the price, and places the order. That can be a handful of orders a week or 50 to 100 a day. The work is usually done part by part from a spreadsheet: type one MPN, check availability, click through to the distributor, and repeat. Authorized distributors get checked first, and the search widens to non-authorized brokers only if nothing is in stock. Many buyers check a second time immediately before ordering, in case something moved overnight.
Every one of those steps has an equivalent above. One API query replaces a hundred separate lookups. Using the authorized-only filter in the API is the same "preferred first, then widen" instinct written as a setting rather than a second round of manual searching. The pre-order recheck becomes a job that runs on a schedule and alerts only when something has changed. What is bought back is not judgment, which stays with the buyer, but the typing and tab-switching that currently consumes it. Pre-negotiated contract pricing still lives with the distributor, so the API is for shortlisting and for catching change, not for replacing the purchase order.
The design engineer
At an OEM, this person owns the electrical design lifecycle from block diagram through component selection, schematic capture, layout, and BOM release. Their governing constraint is blunt: a component that cannot be sourced is a design problem. So Octopart gets used as a validation step, answering "can this part actually be bought, and from more than one place?" and as a discovery tool for finding and comparing candidates. Distributor breadth is itself the signal, because a part stocked by only one distributor (or with multiple distributors but overall inventory diminishing week over week) is a supply chain risk before it is ever a procurement problem.
Run through the API; that check stops being a part-by-part reflex and becomes a gate. Every line of a BOM can be tested at release, and anything with a single distributor, thin stock, or a lifecycle flag can be surfaced before the design is signed off rather than months later. The fear this addresses is specific and expensive: a part going EOL (end of life) after it has been designed in, forcing a redesign. Datasheets can be pulled into your own tooling at the same time, though engineers will still verify specifications against the datasheet itself, as they should.
The component engineer
Found at mid- to large OEMs, particularly in aerospace, defense, automotive, and medical, this person does not usually create new designs. They manage the parts already in production: keeping the approved-parts library current, catching obsolescence before it becomes a crisis, and qualifying alternates when a part is discontinued. At-risk parts sit on a watchlist that gets checked periodically, partly because a discontinued part sometimes returns to market.
A self-checking watchlist is the clearest win in this article. Instead of someone having to remember to revisit a list, a scheduled query walks it and reports exceptions. Because one application can hold the supply and design scopes together, the library can be read on the design side and compared with live market data on the supply side in the same run, turning a periodic manual audit into a standing report. Octopart still opens the funnel rather than closing it: candidate alternates and market availability come from here, while form, fit, function, compliance, and lifecycle verification continue to happen in PLM (product lifecycle management) tools and specialist data providers.
What the three have in common
None of these personas are asking to visit a new website. They are asking for the answer to arrive inside the system they already work in; at the moment it matters, without someone having to go and fetch it. That is what an API is for, and it is close to how Nexar describes its own purpose: to democratize information and bring people together so they can work more efficiently and make smarter business decisions.
Getting set up
- Register at portal.nexar.com with an email address and password, or with Google, Facebook, or Altium 365 credentials. Organizations already using SSO (single sign-on) with Altium 365 can sign in that way.
- Create or join an organization. This step is required. To join an existing one, ask a member to invite you.
- As soon as you register, there will be a pre-built ‘Evaluation’ application available for you to use. You can navigate to Apps and create additional applications if you would like.
- There is a sandbox environment inside the API dashboard that allows you to explore right away. When you are ready to integrate the data into your tool or application, you can navigate to the Authorization tab and retrieve the authentication credentials.
- Take the client ID and client secret from the app’s Authorization tab. They are static credentials. Treat the secret like a password.
- Exchange them for an access token. Nexar uses OAuth 2.0 (Open Authorization, version 2.0), and tokens last for 24 hours. Supply queries use the client credentials grant; design and adm queries use the authorization code grant with the OpenID, design.domain, and user.access scopes.
You can run every example above in a GraphQL editor such as Nitro (formerly Banana Cake Pop) or Postman before writing a line of application code. The endpoints are api.nexar.com/graphql for the API, identity.nexar.com/connect/token for tokens, and files.nexar.com/File/Upload for uploads.
Where to go next
Watch the API in action. Rob Barton, Head of Platform API at Altium, walks through the evolution of Altium's API and runs live queries against Octopart supply data on the OnTrack podcast: Altium API Deep Dive: Opening PCB Data to Developers on YouTube.
Listen to the episode. OnTrack: The PCB Design Podcast, hosted by Zach Peterson.
Explore the data model. Nexar Voyager gives a visual representation of the GraphQL schema.
Read the documentation. Full documentation and a glossary of terms are available at support.nexar.com. Worked code examples are published on the NexarDeveloper GitHub.
