---
title: "Submit Incident or Review data"
method: POST
path: "/rest/operations/1.0/bulk"
tags: ["Operations"]
---

# Submit Incident or Review data

`POST /rest/operations/1.0/bulk`

Update / insert Incident or Review data.

Incidents and reviews are identified by their ID, and existing Incident and Review 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 getIncidentById or getReviewById operation can be used to confirm that data has been stored successfully (if needed).

In the case of multiple Incidents and Reviews being submitted in one request, each is validated individually prior to submission. Details of which entities failed submission (if any) are available in the response object.

A maximum of 1000 incidents can be submitted in one request.

Only Connect apps that define the `jiraOperationsInfoProvider` module can access this resource.
This resource requires the 'WRITE' scope for Connect apps.

## Request body

- union — The payload used to submit (update / insert) Incident data.
  - object
    - `incidents` object[]
      - `schemaVersion` '1.0', required — The IncidentData schema version used for this incident data. Placeholder to support potential schema changes in the future.
      - `id` string, required — The identifier for the Incident. Must be unique for a given Provider.
      - `updateSequenceNumber` integer, required — An ID used to apply an ordering to updates for this Incident 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 Incident and increment that on each update to Jira). Updates for a Incident that are received with an updateSqeuenceId lower than what is currently stored will be ignored.
      - `affectedComponents` string[], required — The IDs of the Components impacted by this Incident. Must be unique for a given Provider.
      - `summary` string, required — The human-readable summary for the Incident. Will be shown in the UI. If not provided, will use the ID for display.
      - `description` string, required — A description of the issue in Markdown format. Will be shown in the UI and used when creating Jira Issues.
      - `url` string, uri, required — A URL users can use to link to a summary view of this incident, 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 incident in that project).
      - `createdDate` string, date-time, required — The timestamp to present to the user that shows when the Incident was raised. Expected format is an RFC3339 formatted string.
      - `lastUpdated` string, date-time, required — The last-updated timestamp to present to the user the last time the Incident was updated. Expected format is an RFC3339 formatted string.
      - `severity` object — Severity information for a single Incident. This is the severity information that will be presented to the user on e.g. the Jira Incidents screen.
        - `level` 'P1' | 'P2' | 'P3' | 'P4' | 'P5' | 'unknown', required — The severity level of the Incident with P1 being the highest and P5 being the lowest
      - `status` 'open' | 'resolved' | 'unknown', required — The current status of the Incident.
      - `associations` object[] — The IDs of the Jira issues related to this Incident. Must be unique for a given Provider.
        - `associationType` 'issueIdOrKeys' | 'serviceIdOrKeys' | 'ati:cloud:compass:event-source' — the type of the association being made
        - `values` string[]
    - `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 '_'.
    - `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.
  - object
    - `reviews` object[]
      - `schemaVersion` '1.0', required — The PostIncidentReviewData schema version used for this post-incident review data. Placeholder to support potential schema changes in the future.
      - `id` string, required — The identifier for the Review. Must be unique for a given Provider.
      - `updateSequenceNumber` integer, required — An ID used to apply an ordering to updates for this Review 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 Review and increment that on each update to Jira). Updates for a Review that are received with an updateSqeuenceId lower than what is currently stored will be ignored.
      - `reviews` string[], required — The IDs of the Incidents covered by this Review. Must be unique for a given Provider.
      - `summary` string, required — The human-readable summary for the Post-Incident Review. Will be shown in the UI. If not provided, will use the ID for display.
      - `description` string, required — A description of the review in Markdown format. Will be shown in the UI and used when creating Jira Issues.
      - `url` string, uri, required — A URL users can use to link to a summary view of this review, 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 review in that project).
      - `createdDate` string, date-time, required — The timestamp to present to the user that shows when the Review was raised. Expected format is an RFC3339 formatted string.
      - `lastUpdated` string, date-time, required — The last-updated timestamp to present to the user the last time the Review was updated. Expected format is an RFC3339 formatted string.
      - `status` 'in progress' | 'outstanding actions' | 'completed' | 'unknown', required — The current status of the Post-Incident Review.
      - `associations` object[] — The IDs of the Jira issues related to this Incident. Must be unique for a given Provider.
        - `associationType` 'issueIdOrKeys' | 'serviceIdOrKeys' | 'ati:cloud:compass:event-source' — the type of the association being made
        - `values` string[]
    - `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 '_'.
    - `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 Incident that is of a valid format will be eventually available in Jira.

Details of which Incidents were submitted and which failed submission (due to data format problems etc.) are available in the response object.

- object — The result of a successful submitIncidents request.
  - `acceptedIncidents` string[] — The IDs of Incidents that have been accepted for submission. A Incident may be rejected if it was only associated with unknown project keys. Note that a Incident that isn't updated due to it's updateSequenceNumber being out of order is not considered a failed submission.
  - `failedIncidents` object — Details of Incidents that have not been accepted for submission, usually due to a problem with the request data. The object (if present) will be keyed by Incident ID and include any errors associated with that Incident 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 Incident has been associated with project keys other than those in this array it will still be stored against those valid keys. If a Incident 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 Incident 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 Incident 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 Incidents 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/versions/4e108d54b990/schema)