# Bulk processing of events

Bulk processing of events refers to the task of publishing,
editing, or cancelling a group of events in a single API call.
Since a unique event has to be created for each traveler when working with
SPD trips or SPD session event types, you can use the following bulk processing APIs to manage these events:

* [**Bulk publish events**](/openapi/eventapi/events/bulkpublishevents): Publishes a group of draft events.
* [**Bulk edit events**](/openapi/eventapi/events/bulkeditevents): Edits a group of events. Both draft and published events can be edited.
* [**Bulk cancel published events**](/openapi/eventapi/events/bulkcancelevents): Cancels a group of events which were published or deletes a group of unpublished events.
* [**Bulk delete draft events**](/openapi/eventapi/events/bulkdeleteevents): Deletes a group of draft events.


> **Note:**
You can only cancel an event if all the bookings associated with the event are inactive
(i.e., PNRs with status `CANCELLED`, `VOIDED`, `CANCELLED_BY_VENDOR`, `INOPERATIVE`, or `UNCONFIRMED`).


For all the bulk processing APIs mentioned above,
if the event `type` is `PROGRAM_TRIP` and the `parentEventId` is set to `templateId`,
then you must send all the `eventIds` in the request to process the events.
However, if the event type is `PROGRAM_SESSION`, you just need to send the
parent event’s `eventId` in the request to process all its associated child events.

> **Note:** For a SPD session event type, [bulk editing](/openapi/eventapi/events/bulkeditevents) only works for [attached child events](/spotnana/spd_types#attached-and-detached-child-events).


## Types of bulk processing

When working with specialty desk events,
you're creating one event per traveler.
So, the total number of events you need to bulk process depends directly on the number of travelers.
For example, if you're adding 500 travelers to an event, bulk publishing will create and
publish 500 draft events and generate 500 trips (one for each traveler).

To update these events, use **synchronous** or **asynchronous** bulk processing based on the volume of data you're handling.

### Synchronous bulk processing

When you make a synchronous API call, the response is returned only after the API is fully processed.
If the API is required to process large number of events (e.g., cancel 500 events),
it could cause potential latency as it first has to process all those events, and the response is only returned after its completion.

Use the synchronous API call when you’re updating fewer events (less than 20).
Set the `updateAsync` field as `false` when [bulk editing](/openapi/eventapi/events/bulkeditevents)
and the `cancelAsync` field as `false` when [bulk canceling](/openapi/eventapi/events/bulkcancelevents) synchronously.

### Asynchronous bulk processing

In an asynchronous API call, an automated job will begin executing the tasks (e.g., publishing 100 events) in batches.
Your API call will receive a success response, however the backend job may take some
time to complete depending on the number of events that require processing.
You can use the [bulk processing job status](/spotnana/spd_bulk_process_status_workflow) workflow to
retrieve the current status (in progress or completed) of the automated job.

Use the asynchronous API call for processing a large number of events (e.g., edit 200 events) in batches.
Set the `updateAsync` field as `true` when [bulk editing](/openapi/eventapi/events/bulkeditevents) and the `cancelAsync` field as `true`
when [bulk canceling](/openapi/eventapi/events/bulkcancelevents) synchronously.
The [bulk publish](/openapi/eventapi/events/bulkpublishevents) API is asynchronous by default without configuring any fields.

> **Notes:**
- See [bulk event processing job status](/spotnana/spd_bulk_process_status_workflow) workflow to learn more about how to retrieve the job status.
- The [bulk delete](/openapi/eventapi/events/bulkdeleteevents) API operates synchronously by default.