# Flush Operations

Flush Operations is used in the [Add/Update Menu](https://api-docs.urbanpiper.com/downstream/v/api-documentation/endpoints/menu/add-update-menu) API request to reset/update the catalogue data in the UrbanPiper system for a given brand. The "Flush" options are available in each catalogue object such as - Categories, Items, Option Groups, and Options. POS Partners are advised to use the Flush Operations to handle the changes related to the menu catalogue update of their merchants in the UrbanPiper system through API.

API URL - <https://pos-int.urbanpiper.com/external/api/v1/inventory/locations/:location\\_id/>

Where, the `:location_id` value changes based on the type of request mentioned below.

Below available `"flush_*"` options take the boolean value:

1. `"flush_categories"`
2. `"flush_items"`
3. `"flush_option_groups"`
4. `"flush_options"`

The above-mentioned **"flush\_\*"** options work differently based on the Type of Request made to Add/Update Menu API. The type of requests are broadly specified below,

1. **Master/Base Level Request** — passing the `:location_id` as **-1** in the API URL.
2. **Location Level Request** — passing the `:location_id` as the actual POS store ID in the API URL.

Ensure the below-defined procedures are implemented at your end in the Add/Update Menu API request for smooth menu catalogue operations from the POS application.

## Categories

The below scenario(s) related to Categories can be handled following the procedures defined.

#### Deactivate certain categories from the menu

1. Make the Master/Base Level Request with `"flush_categories": true`.
2. Pass only the active categories available across all the locations in the request payload

   that the merchant wants to sell on online ordering platforms.

#### Outcome

1. Through this, the old categories present in the UrbanPiper system that were not passed in the request payload will get deactivated.
2. The categories passed in the request payload will be in the *active* state.
3. If there are any new categories passed in the request payload will get created and

   remain in an active state.
4. The categories which are in an active state will not have any category<>location

   the association which is fine.

## Items

The below scenario(s) related to Items can be handled by following the procedures defined,

* Deactivate certain items from the brand menu.
* To associate an item from one category to another category.
* Deactivate the old item<>category mapping from the menu.
* Clear the option groups associated with the item.

#### Procedure

1. Make the Master Level Request with `"flush_items": true`.
2. Pass only the active items associated with the right categories that are available at least

   for one location in the request payload that the merchant wants to sell on the online

   ordering platforms.
3. Make the Location Level Request for the items available with the given location passed

   in the request payload.
4. To remove the previously associated option groups from the item, you can pass `"clear_option_groups": true` in the item's object in the Request.

#### Outcome

1. When you make the Master Level Request with `"flush_items": true`, all the previously created items in the UrbanPiper system will be deactivated and if any new items are present in the request payload will remain in an active state.
2. When you make a Location Level Request, the items passed in the request payload will become active and associated with the location.

If you want to disassociate a few items from a given location, you can simply make the Location Level Request passing the valid items for the location associated with the right category mapping and keeping `"flush_items": true` in the request payload. This will keep the only passed items in the request payload to remain associated with the location. The unpassed items will get disassociated from the location. Hence, those items are no longer available to sell on ordering platforms.

## Option Groups

The below scenarios related to Option Groups can be handled by following the procedures,

* Discontinue OGs from the menu
* Dissociate items from OGs
* Dissociate options from OGs

### Discontinue OGs from the menu

#### Procedure

1. Make the Master Level Request with `"flush_option_groups": true`
2. Pass only the available active option groups mapped to items in the request payload

   which the merchant wants to sell on the online ordering platforms.

#### **Outcome**

1. Through this, the old OGs present in the UrbanPiper system that was not passed in the request payload will be deactivated.
2. The only OGs data passed in the request payload will be in the active state.
3. If there are any new OGs passed in the request payload will get created and remain in an

   active state.

### Dissociate Items from OGs

#### Procedure

1. Make the Master Level request passing the `"clear_items": true` for those OG objects you want to reset the item<>OGs association.
2. Make sure to pass the right association of the IDs of the items under OG's `"item_ref_ids":[]` to create the latest association.

#### **Outcome**

1. Through this action, the Option Group's association with the items will be updated.

### Dissociate options from OGs

#### Procedure

1. Make the Master Level request passing the `"clear_options": true` for that OG objects you want to reset the OGs<>Options association.
2. Make sure to pass the right association of the IDs of the options under Options `"opt_grp_ref_ids":[]` to create the latest association.

#### **Outcome**

1. Through this action, the Option Group's association with the options will be updated.

## Options

The below scenarios related to Options can be handled by following the procedures

* Discontinue Options from the menu
* Disassociate an Option from the OG
* Discontinue Options from the menu

### Discontinue Options from the menu

#### Procedure

1. Make the Master Level Request with `"flush_options": true`.
2. Pass only the available active options mapped with OGs in the request payload which

   the merchant wants to sell on online ordering platforms.
3. Make the Location Level Request with the options available within the given location

   passed in the request payload.

#### Outcome

1. When you make a Master Level Request with`"flush_options":true`, the options which were not passed in the request payload will be deactivated.
2. The options which were passed in the request payload and any options which were newly passed will remain in an active state but the location association won't be present.
3. When you make a Location Level Request, the options passed in the request payload will

   remain active and get associated with the location.

### Disassociate an Option from OG

#### Procedure

1. Make the Master Level Request.
2. Pass `"clear_opt_grps":true` inside those options for which you want to reset/update the OGs<>Option association.
3. Make sure to pass the updated IDs of OGs under `"opt_grp_ref_ids":[]` to update the association.

#### Outcome

1. Through this, first, the existing Option<>OGs mapping will get removed from our system.
2. Later, a new Option<>OGs mapping will get created.
3. When a Location Level Request is made, the newly updated options will get associated

   with the right location. (optional)

### Disassociate an Option from Nested OGs

#### Procedure

1. Make the Master Level Request.
2. Pass `"clear_nested_opt_grps":true` inside those options for which you want to reset/update the nested OGs<>Option association.
3. Make sure to pass the updated IDs of nested OGs under `"nested_opt_grps":[]` to update the association.

#### Outcome

1. Through this, first, the existing Option<>nested OGs mapping will get removed from our system.
2. Later, a new Option<>nested OG mapping will get created.
3. When a Location Level Request is made, the newly updated options will get associated

   with the right location. (optional)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://api-docs.urbanpiper.com/downstream/resources/flush-operations.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.