--- title: "Submit DevOps Components" method: POST path: "/rest/devopscomponents/1.0/bulk" tags: ["DevOps Components"] --- # Submit DevOps Components `POST /rest/devopscomponents/1.0/bulk` Update / insert DevOps Component data. Components are identified by their ID, and existing Component data for the same ID will be replaced if it exists and the updateSequenceNumber of existing data is less than the incoming data. Submissions are performed asynchronously. Submitted data will eventually be available in Jira; most updates are available within a short period of time, but may take some time during peak load and/or maintenance times. The getComponentById operation can be used to confirm that data has been stored successfully (if needed). In the case of multiple Components being submitted in one request, each is validated individually prior to submission. Details of which Components failed submission (if any) are available in the response object. A maximum of 1000 components can be submitted in one request. Only Connect apps that define the `jiraDevOpsComponentProvider` module can access this resource. This resource requires the 'WRITE' scope for Connect apps. ## Request body - object — The payload used to submit (update / insert) DevOps Component data. - `properties` object — Properties assigned to incidents/components/review data that can then be used for delete / query operations. Examples might be an account or user ID that can then be used to clean up data if an account is removed from the Provider system. Properties are supplied as key/value pairs, and a maximum of 5 properties can be supplied, keys cannot contain ':' or start with '_'. - `devopsComponents` object[], required - `schemaVersion` '1.0', required — The DevOpsComponentData schema version used for this devops component data. Placeholder to support potential schema changes in the future. - `id` string, required — The identifier for the DevOps Component. Must be unique for a given Provider. - `updateSequenceNumber` integer, required — An ID used to apply an ordering to updates for this DevOps Component in the case of out-of-order receipt of update requests. This can be any monotonically increasing number. A suggested implementation is to use epoch millis from the Provider system, but other alternatives are valid (e.g. a Provider could store a counter against each DevOps Component and increment that on each update to Jira). Updates for a DevOps Component that are received with an updateSqeuenceId lower than what is currently stored will be ignored. - `name` string, required — The human-readable name for the DevOps Component. Will be shown in the UI. - `providerName` string — The human-readable name for the Provider that owns this DevOps Component. Will be shown in the UI. - `description` string, required — A description of the DevOps Component in Markdown format. Will be shown in the UI. - `url` string, uri, required — A URL users can use to link to a summary view of this devops component, if appropriate. This could be any location that makes sense in the Provider system (e.g. if the summary information comes from a specific project, it might make sense to link the user to the component in that project). - `avatarUrl` string, uri, required — A URL to display a logo representing this devops component, if available. - `tier` 'Tier 1' | 'Tier 2' | 'Tier 3' | 'Tier 4', required — The tier of the component. Will be shown in the UI. - `componentType` 'Service' | 'Application' | 'Library' | 'Capability' | 'Cloud resource' | 'Data pipeline' | 'Machine learning model' | 'UI element' | 'Website' | 'Other', required — The type of the component. Will be shown in the UI. - `lastUpdated` string, date-time, required — The last-updated timestamp to present to the user the last time the DevOps Component was updated. Expected format is an RFC3339 formatted string. - `providerMetadata` object — Information about the provider. This is useful for auditing, logging, debugging, and other internal uses. It is not considered private information. Hence, it may not contain personally identifiable information. - `product` string — An optional name of the source of the incidents. ## Response `202` Submission accepted. Each submitted Component that is of a valid format will be eventually available in Jira. Details of which Components were submitted and which failed submission (due to data format problems etc.) are available in the response object. - object — The result of a successful submitDevopsComponents request. - `acceptedComponents` string[] — The IDs of Components that have been accepted for submission. A Component may be rejected if it was only associated with unknown project keys. Note that a Component that isn't updated due to it's updateSequenceNumber being out of order is not considered a failed submission. - `failedComponents` object — Details of Components that have not been accepted for submission, usually due to a problem with the request data. The object (if present) will be keyed by Component ID and include any errors associated with that Component that have prevented it being submitted. - `unknownProjectKeys` string[] — Project keys that are not known on this Jira instance (if any). These may be invalid keys (e.g. `UTF` is sometimes incorrectly identified as a Jira project key), or they may be for projects that no longer exist. If a Component has been associated with project keys other than those in this array it will still be stored against those valid keys. If a Component was only associated with project keys deemed to be invalid it won't be persisted. ## Other responses - `400` — Request has incorrect format. Note that in the case of an individual Component having an invalid format (rather than the request as a whole) the response for the request will be a 202 and details of the invalid Component will be contained in the response object. - `401` — Missing a JWT token, or token is invalid. - `403` — The JWT token used does not correspond to an app that defines the Operations Information module, or the app does not define the 'WRITE' scope. - `413` — Data is too large. Submit fewer Components in each payload. - `429` — API rate limit has been exceeded. - `503` — Service is unavailable due to maintenance or other reasons. - `default` — An unknown error has occurred. --- [API](https://skmtc.net/atlassian/apis/jira-software-cloud-api.md) · [All operations](https://skmtc.net/atlassian/apis/jira-software-cloud-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/atlassian/jira-software-cloud-api/revisions/4e108d54b990/schema)