The most important API rule is simple:
Something visible on the ped is not automatically something saved for the character.
Use client APIs for visual state/previews. Use server-authorized APIs for persistent editor sessions and database-backed appearance changes.
Persistent editor opens
Server: OpenEditor(source, options)
Use this when another trusted server resource wants to open a save-capable RCO editor.
Server: OpenWardrobe(source, options?)
Preferred integration for houses, hotels, camps and properties. It always forces wardrobe mode. Full guide: Wardrobe integrations.
Client: persistent OpenEditor / OpenWardrobe
A client cannot grant itself persistent editor authorization. Direct persistent opens return:
If you only need a deliberately local/visual editor, use the local-only API provided by your build rather than relying on it to save.
Visual appearance
ApplyAppearance
Applies appearance visually. Useful for previews/mannequins/custom peds.
It is not a database save.
GetAppearance
Reads the current visual appearance of the ped.
Do not blindly persist a live capture just because it came from GetAppearance. The ped may currently be inside a preview, temporarily undressed or carrying a transient gameplay state. For the character’s canonical saved look, use the server persistence API.
Editor / reload helpers
Depending on the use case, the public surface also includes helpers such as editor state and appearance reload. /reloadskin and the server reload path restore the saved RCO appearance rather than treating the current ped as truth.
Character persistence
GetAppearanceForCharacter(charId, callback)
charId is the framework’s character identifier (RSG citizen id / VORP character identifier). Treat it as an opaque identifier in your integration.
SetAppearanceForCharacter(charId, snapshot, callback)
Saving is asynchronous. Wait for the callback before chaining logic that assumes the database write succeeded.
Use this only with a valid RCO snapshot. Do not convert arbitrary third-party skin blobs by renaming fields.
Outfit helpers
Server-side outfit APIs can list/manage the outfits already owned by the active character. For a normal housing integration you usually do not need to rebuild your own UI — call OpenWardrobe instead.
Quick Clothing API
Quick Clothing has its own client/server exports for temporary clothing visibility and transforms:
Server scripts can use:
See Quick Clothing for the full contract and failure reasons.
Appearance apply completion
Appearance emits its internal/public apply-completion hook used by RCO integrations after a player appearance transaction finishes. If your resource only needs normal login timing, prefer the framework lifecycle events documented under Creator lifecycle rather than coupling a HUD/job system to every appearance reload.
Framework compatibility aliases
RCO keeps selected RSG/VORP compatibility names so existing resources can continue to call known appearance helpers. Those aliases are a compatibility layer, not the recommended API for new integrations.
New resources should call:
directly, so the integration behaves the same way on RSG and VORP. 
