> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryoto.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sync order status and tracking to your store

> How OTO maps shipment statuses to your store's order statuses, sends several updates from one event, and adds tracking links to the customer's order page.

> [!NOTE]
>
> **Where to find it:** Main → Integrations → Sales Channels — [Open in OTO ↗](https://app.tryoto.com/sales-channels)

Your customer does not have an OTO account. They have an order page on the store they bought from, and whatever that page says is what they believe.

## Why statuses have to be translated

OTO and your sales channel do not use the same words, and they should not. OTO tracks a shipment through a logistics lifecycle; a storefront tracks an order through a commerce one. **Out for Delivery** is meaningful in the first and has no equivalent in the second.

Status mapping is the translation table between them: for each OTO event, what the channel should be told, and how.

## The mapping table

Open a connected channel’s **…** menu and choose **Status Mapping**. Each row is one rule.

| Column | What it sets |
| - | - |
| **OTO Status** | The event that triggers the update. Values include **Shipment Processing**, **Out for Delivery**, **Delivered**, **Collected**, **Shipment Canceled**, **Confirmed Return** and **Returned**. |
| **Update Type** | *How* the channel is updated — whether this writes an order comment or a shipment record on the channel. |
| **Ecom Status** | The status to set on the channel — written in the channel’s **own status code**, not its display name. A Salla mapping reads `executed`, `shipped`, `delivery`, `delivered`, `restoring`, `restored`. |
| **Ecom Comment** | Free text written alongside it, supporting variables — for example *“Shipped with :deliveryCompany”*. More than one variable can appear in a single comment. |

**Add New Row** adds a rule and each row can be deleted. Mapping is **per channel**, so a marketplace with a strict status vocabulary and your own storefront can be driven differently from the same events. Each column header carries an information tooltip, and the dialog saves as a whole rather than row by row.

> [!WARNING]
>
> **Get the channel’s codes from the channel**
>
> **Ecom Status** is a free-text field, and it is passed to the channel’s API as typed. The channel expects its internal code — `executed`, not *Executed*; `delivery`, not *Out for delivery*.
>
> A near-miss here does not raise an error in OTO. It produces an update the channel rejects, and an order that sits on the wrong status while everything looks configured.

![The Status Mapping dialog showing eight rows mapping OTO statuses to a channel’s own status codes and comments](https://mintcdn.com/oto/ft-bRlLvOnJkbVoC/images/sc-4-status-mapping.png?fit=max\&auto=format\&n=ft-bRlLvOnJkbVoC\&q=85\&s=d542f75d56b961b3c5d7f624c6124c4e)

Fig. 1 — A real mapping. Note that Shipment Processing appears twice with two different update types — and that the Ecom Status column takes the channel’s own codes, not its display names.

## One event, several updates

The same OTO status can appear on more than one row with different **Update Types**. In the mapping above, **Shipment Processing** appears twice: once as an order comment carrying the status and the carrier name, and once as an **Order Shipment** — which is what actually creates the fulfillment record on the channel.

That is the mechanism behind the register’s *custom triggers*. One event can both tell the customer something and write a structured record, because those are different operations on the channel’s side.

> [!NOTE]
>
> **A row with an empty status and comment does nothing**
>
> Rows are allowed to carry an OTO status and an update type with both right-hand fields blank. Nothing warns you, and the mapping screen looks complete.
>
> If a status is not reaching the channel, check the row exists *and* that it has something to say. A blank row is indistinguishable from a missing one from the customer’s side.

> [!TIP]
>
> **Map fewer statuses than you think, and map them well**
>
> Every status you forward is a message the customer reads. Forwarding all of them turns an order page into a logistics feed; forwarding none of them leaves it frozen on **Processing**.
>
> The three that almost always earn their place are *dispatched*, *out for delivery* and *delivered*. Add returns if you take them — a refund the customer cannot see the progress of generates more contacts than the return itself.

## Tracking links

The second thing written back is how the customer follows the parcel, and there is a real choice here.

| Option | Where the customer lands | Trade-off |
| - | - | - |
| **Branded tracking link** | Your own [tracking page](https://docs.tryoto.com/modules/customer-notification/branded-pages.md), on your domain and in your identity, showing normalized statuses from whichever carrier is involved. | You own the experience, and the carrier is an implementation detail rather than a brand the customer remembers. |
| **Carrier tracking link** | The carrier’s own tracking site. | Familiar to some customers, and the right answer where a carrier’s page carries information yours cannot — but it hands off your customer mid-purchase. |

> [!TIP]
>
> **The tracking page is the most-visited page you own**
>
> A customer who has ordered something checks on it more than once. That traffic is already yours and it is already engaged — sending it to a carrier’s site gives it away, along with every impression on it.
>
> The branded link also survives a carrier change. A tracking URL on your own domain keeps working when you switch carriers; the carrier’s does not, and neither do the emails that quoted it.

## Related

* [Branded pages](https://docs.tryoto.com/modules/customer-notification/branded-pages.md) — the tracking page itself.
* [Shipping and tracking](https://docs.tryoto.com/modules/shipping-management/shipping-and-tracking.md) — where the statuses come from.
* [Channel sync](https://docs.tryoto.com/modules/sales-channels/sync.md) — the connection these updates travel on.


## Related topics

- [Connect and sync a sales channel](https://docs.tryoto.com/modules/sales-channels/sync.md)
- [Sales Channels](https://docs.tryoto.com/modules/sales-channels/overview.md)
- [Order sync: how orders get into OTO](https://docs.tryoto.com/modules/omnichannel-oms/order-sync.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.