Choose between O*NET Web Services and a locally hosted copy of the O*NET Database before designing your app: the API reduces update work and offers documented exploration features, while the downloadable database gives you more control over querying and storage. The right choice depends on how current the data must be, which features you need, and whether your distribution model meets the separate license and service terms.
Choose how your app will get O*NET data
O*NET offers two main delivery models. The Web Services are a REST API for occupation information and exploration features. Alternatively, you can download the database and build your own data layer. A hybrid design is also possible, but each source has its own obligations.
As an Amazon Associate I earn from qualifying purchases.
| Approach | Good fit when | Trade-offs to plan for |
|---|---|---|
| O*NET Web Services | You want documented services for keyword search, occupation reports, assessments, crosswalks, or other supported features. | Requests require an API key, and your use is governed by Web Services account, attribution, content-use, and distribution terms. O*NET manages access to current service data, but your app depends on the service being available. |
| Download and host the O*NET Database | You need local queries, offline operation, custom joins, or control over your storage and application architecture. | You take responsibility for importing releases and reviewing changes. The O*NET download page currently lists database version 31.0 in Excel, CSV, and JSON formats; it identifies the occupation taxonomy as O*NET-SOC 2019. |
| Hybrid | You want local occupation records alongside selected live exploration features supported by Web Services. | Track provenance and licensing separately for each source. Do not turn API results into a redistributable upstream data service: Web Services terms do not grant third-party republication rights. |
O*NET describes its database API as a way to access the latest version without managing quarterly or annual downloads. If you instead host a downloaded copy, establish a release-review and update process; check the official release information when implementing because the schedule and changes can differ across tables.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Design the career exploration journey
Search by title, phrase, or occupation code
Let people start with words they know, such as a job title or phrase, and also support lookup by O*NET-SOC code. O*NET keyword search can match words, phrases, titles, and full or partial O*NET-SOC codes. Alternate titles in the database can help bridge the gap between a person’s everyday wording and an occupation record.
#1 Best Overall
Make occupation records comparable
Build a report around the information people need to evaluate a path: tasks, knowledge, skills, abilities, technology skills, education, work activities, work context, Job Zone, interests, and related occupations. O*NET services document report information for more than 900 occupations, according to the National Center for O*NET Development’s 2024 Supporting Statement for the O*NET Data Collection Program.
A shortlist or comparison view can organize those fields into practical questions: What does the work involve day to day? Which skills and knowledge recur? What preparation is described? What is the work context? Which related occupations might be worth exploring? These are useful comparison axes, not a promise that the data alone can make a personalized career decision.
Add optional discovery routes deliberately
If your audience includes Spanish-speaking users or people transitioning from military service, evaluate O*NET’s documented Spanish keyword and military occupation search services. Using an official search path is preferable to inventing equivalencies between military roles and civilian occupations.
An Interest Profiler flow can connect assessed interests to occupation suggestions, but its content is a separately licensed tool, not just another database field. Decide whether you will reproduce it unchanged or adapt it before implementation.
Build around stable occupation identity
Use the O*NET-SOC code as the occupation identifier in your data model. Keep the source version and provenance with locally ingested records so you can trace which release a result came from and handle updates deliberately.
- Index alternate titles alongside occupation records so searches can find familiar job names.
- Keep official related-occupation relationships distinct from your own recommendations or ranking logic.
- Store external or third-party material in separate fields from O*NET data; a Web Services response may contain material that is outside the O*NET data license.
- When refreshing a local database, compare release information and preserve a clear record of the source version used by the app.
Implement Web Services access safely
- Register the project. Register before using Web Services. The account setup asks about the organization and product using the data; use the registered project and app URL as directed by O*NET.
- Authenticate API v2 requests. The reference manual documents API version 2.0 and requires the key in an
X-API-KeyHTTP request header. Do not put the key in a query string or request body. - Protect credentials. Keep the key server-side where possible. O*NET documents a browser-side identifier and CORS option for client-side use, but that does not make a private credential safe to expose in browser code.
- Use the documented response formats and transport. Web Services are documented as REST over HTTPS, with JSON and XML responses. Select the service family that matches the feature rather than trying to reproduce a supported service from scratch.
- Cache and pace requests. The API documentation says there is no maximum rate limit imposed by the API itself, but recommends delays for batch work and caching for high-volume real-time use. The Terms of Service state that usage above 5 requests per second or 50,000 requests per day may be throttled or suspended.
Keep the three licensing questions separate
| Asset | What to account for |
|---|---|
| O*NET Web Services data | Maintain an account in good standing, register the product URL, show the required prominent linked credit, and present the data without changes that materially alter its accuracy, attribution, or intent. The service terms also restrict republication to third parties. |
| Downloaded O*NET Database | The download page identifies version 31.0 under CC BY 4.0. Credit the version and USDOL/ETA, link to the license, and identify changes you make. This database license is separate from the Web Services terms. |
| Interest Profiler and other tool content | Tool content has its own terms. CC BY-ND 4.0 allows redistribution of the tool unchanged with attribution; adaptations use the O*NET Tools Developer License and require product validation. Do not assume database or API permissions cover a tool. |
For O*NET branding, use the name adjectivally—for example, “with O*NET data”—and follow O*NET’s trademark requirements. For a Web Services-powered interface, place the required source credit prominently and link it to O*NET Web Services. For database content, use the version-specific attribution required by its license. Follow the applicable source’s exact attribution instructions rather than treating one credit line as sufficient for every asset.
Check the access model before charging or gating
The Web Services Terms of Service require advance Center permission for a paid or registration-required application release that is not also available in a free, publicly accessible application or area. Whether a particular app falls within that condition depends on its access and release design. Map the actual product model to the current terms before launch; the database’s CC BY license does not override separate Web Services conditions.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteTurn the choice into a release plan
- Choose the source: use Web Services for documented live exploration features; host the database when local control or offline use is central.
- Separate the content: track API data, database records, tools, and third-party material with their source and applicable terms.
- Build discovery: connect user-entered titles to O*NET-SOC records through keyword matching and alternate titles, then expose related occupations as a distinct exploration route.
- Plan operations: keep Web Services credentials protected, cache responsibly, and schedule local release reviews if hosting the database.
- Review distribution: confirm attribution, modification, tool-use, and paid-or-gated access requirements before publishing.
O*NET offers useful building blocks, not an endorsement of an app or its modifications. The National Center’s 2024 Supporting Statement reports over 3,800 Web Services user accounts and approximately 20 million requests per month as historical context reported for April 2023; it is not a current usage estimate. The same statement reports more than 30 million requests per month in a program-statistics passage without an explicit observation month, so that figure should not be treated as a verified current traffic rate.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
