Build on Feather

Use these references to configure Feather resources and integrate your own gameplay systems. Each resource owns a focused responsibility; shared development utilities live in Toolkit.

Start hereFramework resources

Core contracts, Character sessions, Roles, Routing, World, Settings, HUD, Admin, and more.

Explore resources →Developer kitToolkit

Owned entities, blips, controls, prompts, rendering, and clipboard utilities.

Open Toolkit →Gameplay systemInventory

Server-authoritative instances, ledgers, access, transactions, equipment, and item-owner hooks.

Read Inventory →InterfaceMenu v2

The official Feather menu system: build NUI menus, pages, tabs, and controls from Lua.

Read Menu v2 →

Existing resources using feather-menu still need Legacy: Menu v1. Menu v2 is the official system for new Feather development and uses a different API. Keep Legacy until the resources that depend on it have migrated.

API conventions

Most current Feather contracts use named exports and return a structured result:

{ ok = true, value = value, meta = optionalMeta }
{ ok = false, code = 'stable_code', message = 'Safe summary', details = optionalDetails }

Always check result.ok == true before reading result.value. Calls that mutate gameplay state belong on the server unless a resource reference explicitly marks an export as client-side.

Finding the right owner

• Use Core for accounts, sessions, providers, RPC, locale, guards, policy, events, and notification dispatch.
• Use Toolkit for reusable client utilities that do not own a gameplay domain.
• Use the named gameplay resource for domain state such as Character, Inventory, Roles, Routing, or World.
• Pages labeled REVIEW describe an older surface that does not currently map to a cloned resource. Treat them as migration context, not a current contract.