# Multi-Brand Workflow

The support for managing multiple brands within a single Atlas portal was recently released, marking a significant advancement in the capabilities of the UrbanPiper platform. The ability to handle multiple brands as part of a single account (referred to as “Biz” in the context of Atlas) has been a longstanding request. The primary beneficiaries of this feature would be Cloud/Dark kitchens, which are experiencing a substantial increase in numbers (a significant shift in the restaurant industry by itself).

This document aims to explain how this feature benefits our customers and how end users can implement it for their upcoming Cloud/Dark kitchen setups.

Unlike the traditional approach of creating separate Atlas dashboards for each brand, you can now onboard multiple brands of a single business entity under one unified Atlas dashboard. This eliminates the need for storing multiple Atlas dashboard logins to access data from different brands, as well as multiple API keys or biz IDs to make API requests. Instead, you can use a single Atlas dashboard login and a single API key-value pair for making API requests.

Let's consider an example of a multi-brand business to help you grasp the concept more easily.

**Business Entity** - <mark style="color:blue;">UrbanPiper Foodworks & Beverages Limited</mark>

Within this business entity, there are four distinct brands operating at each physical location.

| Brands        |
| ------------- |
| Pizza Piper   |
| Burger Boo    |
| Crystal Bowls |
| Biryani Blast |

To accomplish this, the partner must manually create the **Brands** within the Atlas dashboard.

<figure><img src="/files/PLNE6CtEYM9aDUg6gFY1" alt=""><figcaption><p>brands</p></figcaption></figure>

Subsequently, the partner needs to create the physical **Locations** and associate them with the **Brands**.

<figure><img src="/files/gXQC2rthI6YJJDAffoOl" alt=""><figcaption><p>location-brand association</p></figcaption></figure>

<figure><img src="/files/nLAxMutU7qtDaFSlGBWM" alt=""><figcaption><p>physical location</p></figcaption></figure>

You will notice the brands listed under the physical locations. All the brands associated with the physical locations will be displayed beneath each respective location.

{% hint style="info" %}
The POS ID is now assigned at the location<>brand level.
{% endhint %}

<figure><img src="/files/HXmLoDGINWNs2ycOGSA9" alt=""><figcaption><p>location-brand</p></figcaption></figure>

All the procedures mentioned above must be configured manually using the Atlas dashboard. Kindly ensure that you follow these instructions.

Given that the POS ID is assigned at the location<>brand level, it is expected that partners maintain a unique POS ID for each location<>brand combination.

{% hint style="danger" %}
Configuring the same POS ID for all brands within the same physical location is **NOT** supported.
{% endhint %}

For instance, if the POS partner employs the same physical location ID for all brands, they can establish a unique ID by combining the physical location ID with the brand ID.

Let's take an example: Here are the Physical Locations along with their respective IDs managed by the POS system.

| Physical Location | Location ID |
| ----------------- | ----------- |
| Canary Wharf      | ABHFJI      |
| SouthField        | ERGERT      |

And below, you can find the brands along with their respective IDs maintained in the POS system.

| Brands        | Brand ID |
| ------------- | -------- |
| Pizza Piper   | PPR      |
| Burger Boo    | BBO      |
| Crystal Bowls | CBS      |
| Biryani Blast | BBT      |

When configuring the location<>brand POS ID in the Atlas dashboard, ensure that it is made unique, as shown below:

<table><thead><tr><th width="381.3333333333333">Location Brand</th><th>POS ID</th></tr></thead><tbody><tr><td>Canary Wharf - Pizza Piper</td><td>ABHFJI-PPR</td></tr><tr><td>Canary Wharf - Burger Boo</td><td>ABHFJI-BBO</td></tr><tr><td>Canary Wharf - Crystal Bowls</td><td>ABHFJI-CBS</td></tr><tr><td>Canary Wharf - Biryani Blast</td><td>ABHFJI-BBT</td></tr><tr><td>SouthField - Pizza Piper</td><td>ERGERT-PPR</td></tr><tr><td>SouthField - Burger Boo</td><td>ERGERT-BBO</td></tr><tr><td>SouthField - Crystal Bowls</td><td>ERGERT-CBS</td></tr><tr><td>SouthField - Biryani Blast</td><td>ERGERT-BBT</td></tr></tbody></table>

During the process of syncing the menu using the [Add/Update Menu](https://api-docs.urbanpiper.com/downstream/v/api-documentation/endpoints/menu/add-update-menu) API, it is essential to synchronize the menu for each location<>brand by utilizing the specified POS ID combination mentioned above.

{% hint style="info" %}
If your system already maintains unique POS IDs for each location<>brand, you can directly use them without adhering to the previously mentioned approach.
{% endhint %}

Orders, status updates, rider updates, and all the callbacks originating from our system will include the brand-location POS ID. Additionally, the brand name will be visible at the order details level in the Order Relay payload.

```
"brand": {
        "logo_url": null,
        "id": 106,
        "name": "New Cafe Brand"
      },
```

If you are making [Store Toggle](https://api-docs.urbanpiper.com/downstream/v/api-documentation/endpoints/stores/store-toggle) and [Menu Toggle](https://api-docs.urbanpiper.com/downstream/v/api-documentation/endpoints/menu/menu-toggle) API requests, you are required to provide the location<>brand combination POS ID. This same ID is also expected in the callbacks.

I hope this provides you with an understanding of how to manage Multibrand via POS Integration.

Should you encounter any technical inquiries regarding this concept, please don't hesitate to contact <pos.support@urbanpiper.com>.


---

# 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/multi-brand-workflow.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.