O*NET API: free occupational data from the Department of Labor

O*NET is the US Department of Labor’s occupational database: every one of the roughly 900 O*NET-SOC occupations profiled with its skills, knowledge areas, tasks, technologies, work activities and outlook. O*NET Web Services is the free API over that database, and it belongs on the same short list as USAJOBS for genuinely free, genuinely useful government data APIs. It is also routinely misunderstood: people arrive expecting job listings and find an encyclopedia. Both facts matter, so here is what it actually returns and where it runs out.

Getting access

Register for a free developer account at services.onetcenter.org, agree to the terms, and you get credentials for authenticated requests - minutes, not procurement. Responses come back as JSON or XML. The license asks for attribution and is otherwise permissive; the underlying database itself is published under a Creative Commons attribution license, which is about as good as licensing gets in this industry.

What the API returns

The core surfaces: keyword search across occupations (send “machine learning”, get ranked O*NET-SOC matches), full occupation reports (summary and detail views of skills, tasks, knowledge, abilities, work context and wages via the BLS link), technology and tools lists per occupation including the “hot technology” flags, career outlook and Bright Outlook markers, and crosswalks - the quiet workhorse - mapping O*NET-SOC to and from military occupation codes, education program (CIP) codes, apprenticeship (RAPIDS) codes and the older DOT system.

The taxonomy detail worth knowing before you model anything: O*NET-SOC is the 2018 SOC plus a decimal suffix. 15-1252.00 is Software Developers; where O*NET needs finer grain it mints codes like 15-2051.01 (Business Intelligence Analysts) under the SOC parent. Anything keyed to plain SOC joins cleanly against O*NET by truncating the suffix.

The download most builders should use instead

If you are enriching data in bulk - classifying postings, building a skills feature, training a model - do not loop over a rate-limited web API. The entire O*NET database ships as downloadable files, refreshed on a quarterly-ish release cycle, importable into Postgres in an afternoon. The API is the right tool for interactive lookups and always-current single queries; the download is the right tool for everything else. This split - API for freshness, files for bulk - is the same decision we cover for postings data in job postings datasets.

What O*NET structurally cannot tell you

O*NET describes occupations in the abstract - what a software developer generally does, generally needs to know. It is a reference book, not a market feed. It cannot tell you who is hiring software developers this week, what they are offering, which skills employers started asking for last quarter, or how demand differs between Austin and Atlanta. Its update cycle is measured in quarters and its content in years; the labor market moves in days.

The productive pattern is the join, not the choice: O*NET gives every occupation a stable spine of skills and codes; live postings give you the current demand hanging off that spine. Classify postings to O*NET-SOC, then you can put “what the government knows about this occupation” and “what 4,000 employers posted this month” in the same query. The postings half of that join is one normalized API call away, and the vendor landscape for it is in labor market data sources.