> ## Documentation Index
> Fetch the complete documentation index at: https://rust-co.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Wardrobe integrations

> Open RCO saved outfits from houses, hotels, camps and custom interiors.

A housing or hotel script usually already knows **when** a player is allowed to use a wardrobe: they own the room, have a key, are inside the right house, passed the interaction check, and so on.

RCO does not need to replace that logic. Once your script authorizes the interaction, ask RCO to open the character's saved outfits.

## Use the server export

From server code:

```lua theme={"dark"}
local ok = exports['rco-appearance']:OpenWardrobe(source)
```

You can also pass an options table if your integration needs one:

```lua theme={"dark"}
local ok = exports['rco-appearance']:OpenWardrobe(source, {
    -- optional context supported by your build
})
```

`OpenWardrobe` forces the editor into **`wardrobe` mode**.

It does not create a physical tailor session and does not give the player access to buy arbitrary clothing. It opens the saved-outfit experience only.

## Example: hotel room

```lua theme={"dark"}
RegisterNetEvent('my-hotel:server:openWardrobe', function(roomId)
    local src = source

    if not PlayerCanUseRoomWardrobe(src, roomId) then
        return
    end

    exports['rco-appearance']:OpenWardrobe(src)
end)
```

Your hotel resource decides ownership/access. RCO handles the wardrobe UI, saved outfits and appearance persistence.

## Why it is server-side

Persistent editor sessions are server-authorized. A random client should not be able to grant itself a save-capable wardrobe/editor lease.

For that reason, this is the canonical integration:

```lua theme={"dark"}
-- server
exports['rco-appearance']:OpenWardrobe(source)
```

Calling the client-side `OpenWardrobe`/persistent `OpenEditor` path directly is intentionally rejected with:

```text theme={"dark"}
server_authorization_required
```

## Client-only visual previews are different

There are legitimate cases where a script wants a local visual editor/preview without persistence. That is a different trust model and should use the explicitly local API where appropriate rather than pretending the session can save.

For real houses/hotels, use the server export.

## One wardrobe database

Do not copy RCO outfits into a separate housing table unless you have a very specific reason. The whole benefit of this integration is that the character sees the same saved outfits everywhere:

```text theme={"dark"}
Tailor wardrobe
Hotel room
Owned house
Camp tent
Custom property interior
        ↓
Same RCO saved outfits
```

## Recommended interaction flow

```text theme={"dark"}
Player interacts with wardrobe point
  ↓
Your resource validates access server-side
  ↓
OpenWardrobe(source)
  ↓
RCO opens saved outfits
  ↓
Player previews/wears outfit
  ↓
RCO persists the selected appearance through its normal wardrobe path
```

## Do not use a tailor as a wardrobe shortcut

Opening `clothing` mode from a hotel room would expose clothing-shop behavior that your housing resource probably did not intend to grant.

Use `OpenWardrobe` when the feature is **"change into an outfit I already own/saved."**

Use the general server `OpenEditor(source, options)` only when you intentionally want another editor mode and understand its authorization/persistence behavior.