---
sourceDocument: Australia Security Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/security-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Security Management

ft:clusterId :

    - security

bundleId :

    - security

workflow :

    - Technology


---

# Uploading Software Bill of Materials files using a REST API

# Uploading Software Bill of Materials files using a REST API {#ariaid-title1}

* Release version: Australia
* 
* Updated June 25, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Uploading Software Bill of Materials files using a REST API

This guide explains how ServiceNow customers can upload Software Bill of Materials (SBOM) files using the REST API available in SBOM Core version 4.0 (Australia release).
The API supports ingestion of SBOM files in CycloneDX (XML and JSON, versions 1.0 to 1.6) and SPDX (JSON, versions 2.2-2.3) formats.
Users must have thesnsbomcore.sbomingestrole to use the upload API.
Show full answer Show less  
SBOM file uploads allow you to integrate detailed software component data into your ServiceNow instance, enabling vulnerability and package intelligence integrations when requested.

## Using the Upload API

* **Endpoint:** POST `https://<instancename>/api/sbom/core/upload`
* **Required Header:** `Content-Type` must be set to `application/json`, `text/xml`, or `application/xml` depending on the SBOM file format.
* **File Size Limit:** Files larger than 32 MB may fail to upload properly.
* **Request Body:** Contains the SBOM file content. Additional optional parameters can map the SBOM to products, business applications, or specify the SBOM source.
* **DevOps Integration:** If `requestedBy` is set to "devops," `buildId` and `lifecycleStage` parameters are mandatory. Flags for fetching vulnerability and package intelligence info (`fetchVulenrabilityInfo`, `fetchPackageInfo`) can also be included.

## Request Parameters

* **productModelId** and **businessApplicationId**: Sys IDs to associate the SBOM with existing models or applications.
* **sbomSource:** The tool or product source of the SBOM, e.g., Veracode.
* **requestedBy:** The tool or methodology initiating the upload (e.g., Jenkins, devops).
* **buildId:** Identifier for the build (mandatory if requestedBy is "devops").
* **lifecycleStage:** Indicates if the SBOM is for "production" or "preproduction" (mandatory if requestedBy is "devops").
* **fetchVulenrabilityInfo** and **fetchPackageInfo:** Boolean flags to trigger vulnerability and package intelligence lookups.

## Response and Status API

The upload API response includes a status, message, and `bomRecordId` which identifies the SBOM record in ServiceNow.

To check the processing status of an uploaded SBOM, use the Status API:

* **Endpoint:** GET `/api/sbom/core/upload/status`
* **Parameter:** `bomRecordId` returned from the upload response.

The status response provides details on ingestion status, component counts, and if requested, vulnerability and package info summaries.

## Post-Upload Processing and Viewing Data

After a successful upload, the SBOM data is parsed and stored in the **Bill of Materials \[snsbomdoc\]** table with components represented as BOM Entities. Third-party components are identified by type=library.

Uploaded SBOM records can be viewed in the SBOM Ingestion Status list within the BOM Queue module of the SBOM Workspace or under SBOM Core \> BOM Ingestion Status, depending on the applications in use.

## Enhancements and Supported Standards

* SBOM Core v4.0 supports enhanced CycloneDX versions 1.0 to 1.6 (XML/JSON) and SPDX versions 2.2 to 2.3 (JSON).
* Optional property `snsbomcore.collectproperties` can be activated to import additional metadata, vulnerabilities, and component properties not normally supported.
* Support for new CycloneDX component types including Platform, Data, Device driver, Machine Learning model, and Cryptographic components.
* SBOM file validation ensures format support and required fields before ingestion.

## Practical Considerations for ServiceNow Customers

* Ensure your user account has the `snsbomcore.sbomingest` role for API access.
* Verify `Content-Type` headers are correctly set to avoid request rejections.
* Use the Status API to monitor ingestion progress and retrieve vulnerability or package intelligence data if enabled.
* Map your SBOM files to existing product models or business applications to maintain traceability in your environment.
* Leverage DevOps parameters for automated build integration and lifecycle stage tagging  
Review the following information prior to uploading Software Bill of Materials files using an API.

## Using the REST API {#vr-sbom-preparing-upload__section_u41_c3p_xzb}

To upload an SBOM file with an API, the sn_sbom_core.sbom_ingest role is required.

Upload API.

This API is used for uploading and ingesting an SBOM file (CycloneDX/SPDX) into your instance.  
Version 4.0 of SBOM Core supports:

* XML and JSON in CycloneDx (versions 1.0 - 1.6).
* JSON in SPDX (versions 2.2-2.3)
* Note:  
  Files over 32 MB might not load properly.
{#vr-sbom-preparing-upload__ul_rys_3wh_2cc}

HTTP method: (POST)  
API URL: \<host_name\>/api/sbom/core/upload  
Note:  
\<host_name\> is your ServiceNow instance name.

Request headers.  
The Content-Type header is required when calling the Upload API. Set the Content-Type value to match the SBOM file content submitted in the request body. Supported values include:

* Content-Type: text/xml
* Content-Type: application/json
* Content-Type: application/xml

{#vr-sbom-preparing-upload__ul_l25_jvn_rjc}If the Content-Type header is missing, the API rejects the request with a HTTP 400 error and returns the following code:

    {
      "status": "failure",
      "message": "Content-Type header is missing"
    }

If the Content-Type header is unsupported, the API rejects the request with an HTTP 400 error and returns the following code:

    {
      "status": "error",
      "message": "Unsupported Content-Type. BOM data must be in JSON or XML."
    }

All the following request parameters are optional; the request body is the SBOM file content. If you're using DevOps as part of your development process, the value of 'requestedBy' should be 'devops'. See [Uploading Software Bill of Materials for DevOps SBOM files](https://servicenow-prod.fluidtopics.net/4~lS694nGLL0WEQvORukog "Generate and upload Software Bill of Materials SBOM files for software throughout its continuous integration and continuous deployment development cycles.") for more general information about DevOps. If the value for 'requestedby' is "devops" (devlopment operations), these parameters are mandatory:

* buildId
* lifecycleStage
{#vr-sbom-preparing-upload__ul_p3t_z3h_2cc}  
In addition, if 'requestedBy' is 'devops', data for fetchVulenrabilityInfo, and fetchPackageInfo is included.

* buildId- string you send
* lifecycleStage- two values, production or pre_production
* fetchVulenrabilityInfo- t/f
* fetchPackageInfo-t/f
{#vr-sbom-preparing-upload__ul_j2m_ybh_2cc}
{#vr-sbom-preparing-upload__table_fsh_lgh_2cc__entry__3}

| Request parameters | Possible values | Description |
|-|-|-|
| productModelId | Sys id | Sys id of product model to map with the root application of given SBOM. |
| businessApplicationId | Sys id | Sys id of business application to map with the root application of given SBOM. |
| businessApplicationName (deprecated) | Your business application name | Name of business application to map with the root application of given SBOM. |
| sbomSource | A product such as Veracode, for example | The source for your SBOM file. |
| requestedBy | A tool, or name of a methodology, Jenkins. If you use "devops", buildId and lifecycleStage are mandatory. | Upload requested by |
| buildId | A string requester sends. | Build ID of the SBOM build. |
| lifecycleStage | production or pre_production | Life cycle stage of the entity. |
| fetchVulenrabilityInfo | t/f | If true, triggers vulnerability intelligence integration. |
| fetchPackage Info | t/f | If true, triggers package intelligence integration. |
[ ]

{#vr-sbom-preparing-upload__table_fsh_lgh_2cc}  
Upload API Response: included 'status' success/fail, 'message' (string), 'bomRecordId' (this is the sys id of the SBOM that is returned through the upload API for a successful SBOM upload).

    {

    "result": {

    "status": "success",

    "message": "Queued for processing.",

    "bomRecordId": "f207059b4393c290629aa597cbb8f247"

    }

    }

## Status API {#vr-sbom-preparing-upload__section_jzy_rjh_2cc}

This API gets the status and summary of an SBOM that Is queued for ingestion.

* API URL: /api/sbom/core/upload/status
* HTTP method (GET)
{#vr-sbom-preparing-upload__ul_pvm_3ch_2cc}
{#vr-sbom-preparing-upload__table_rw2_fkh_2cc__entry__3}

| Request parameters | Possible values | Description |
|-|-|-|
| bomRecordId | Sys id | SBOM record ID that is returned the through the upload API for a successful SBOM upload. |
[ ]

{#vr-sbom-preparing-upload__table_rw2_fkh_2cc}

Status API default response example.


    {
       "result": {
          "bomRecordId": "0407c0fea3e70a505df340f5251e617e",
          "uploadStatus": "processed",
          "additionalInfoStatus": "not_requested",
          "uploadSummary": {
             "components": {
                "added": 0,
                "removed": 0,
                "total": 70
             }
           }
        } 
    }

Status API response with additional parameters example. If you requested fetchVulenrabilityInfo for that SBOM, you get the vulnerability breakdown as part of the response.


    {
     "result": {

      "bomRecordId": "93af349b4393c290629aa597cbb8f258",

      "uploadStatus": "processed",

      "additionalInfoStatus": "complete",

      "uploadSummary": {

        "components": {
     
         "added": 0,

         "removed": 0,

         "total": 3

       },

       "vulnerabilityInfo": {

        "critical": 0,

        "high": 0,

        "medium": 0,

        "low": 0,

        "none": 0

       }

      },

      "buildId": "1"

     }

    }

If you requested fetchPackageInfo for that SBOM, you get stale and abandoned counts as part of the response.

After an SBOM is successfully processed, where you view the uploaded records depends on the applications you're using.

* If you're using SBOM Response, the BOM Entity record is displayed on the SBOM Ingestion Status list in the BOM Queue module in the SBOM Workspace.
* If you're using SBOM Core, navigate to SBOM CoreBOM Ingestion Status.
{#vr-sbom-preparing-upload__ul_dtp_21v_xzb}

## Enhancements to supported SBOM standards and general usage information {#vr-sbom-preparing-upload__section_em2_wbp_xzb}

Version 4.0 of SBOM Core supports:

* XML and JSON in CycloneDx (versions 1.0 - 1.6).
* JSON in SPDX (versions 2.2-2.3)
* Note:  
  Files over 32 MB might not load properly.
{#vr-sbom-preparing-upload__ul_hj5_vbb_2cc}  
Starting with v4.0 of SBOM Core, the following enhancements were made to support CycloneDx standards for versions 1.0 - 1.6:

* Import additional information in CycloneDX SBOM files with the (sn_sbom_core.collect_properties) property. This property is deactivated by default. Activate the property to import information that is generally not supported. Any information imported from these properties is uploaded to the SBOM Component Property \[sn_sbom_comp_property\] table for the following:
  * Uploaded SBOM files
  * Metadata
  * Individual vulnerabilities
  * Components
  {#vr-sbom-preparing-upload__ul_v5n_gbb_2cc}
* View imported component data for declared and concluded licenses for SBOM files in versions 1.4 and later of CycloneDX in two new license fields:
  * Declared
  * Concluded
  {#vr-sbom-preparing-upload__ul_dv2_1bb_2cc}
* SBOM parsing support is extended for the following CycloneDX component types:
  * Version 1.5: Platform, Data, Device driver, Machine Learning model
  * Version 1.6: Cryptographic
  {#vr-sbom-preparing-upload__ul_ayz_mbb_2cc}
{#vr-sbom-preparing-upload__ul_xp2_y1b_2cc}  
Version 3.0 of SBOM Core supports:

* XML and JSON in CycloneDx (up to and including version 1.4).
* JSON in SPDX (up to and including v2.3).
{#vr-sbom-preparing-upload__ul_h1l_1yh_2cc}

If the calling user is successfully authenticated and has the sn_sbom_core.sbom_ingest role in your ServiceNow instance, you can access the API from outside of your instance to upload the SBOM data.

After data is uploaded, it is parsed. Before data is parsed, the following requirements are verified:

* Incoming data is checked that it is valid JSON or XML.
* The BOM format is supported. Starting with v2.1 of SBOM Core, CycloneDX (JSON and XML) and SPDX (XML) formats are supported.
* The minimum fields are available so that data can be parsed.

{#vr-sbom-preparing-upload__ul_rrd_fcp_xzb}

After these checks are verified, an entry is made into the Bill of Materials \[sn_sbom_doc\] table with incoming SBOM data as an attachment.  
The Process BOM file business rule is triggered automatically as a result of the record insertion and data parsing.  
Note:  
This business rule is activated during installation of SBOM Core by default.

All the components listed in an SBOM have a defined type.

* Components for which SBOM files were uploaded are considered BOM Entities.
* Components listed as type=library are considered third-party components.
{#vr-sbom-preparing-upload__ul_srd_fcp_xzb}
**Related concepts**   

* [Viewing reports and dashboards in the Software Bill of Materials workspace](https://servicenow-prod.fluidtopics.net/y_jtoeqbUC6WVIUzom44GQ "Vulnerability analysts view uploaded software bill of materials files in records, data visualizations, as well as enhanced vulnerability intelligence in the Software Bill of Materials (SBOM) Workspace.")  
**Related tasks**   

* [View upload status for Software Bill of Materials files](https://servicenow-prod.fluidtopics.net/q6KZMmj4XHgo3~rsrCeFhA "Check the upload status for the Software Bill of Materials (SBOM) files that you upload in the BOM Queue module in the Software Bill of Materials (SBOM) Workspace. Track the files that you upload successfully, your upload history, and errors.")

*[\>]: and then