ESX Legacy for FiveM: what it is, common mistakes and the AI skill

ESX Legacy is the framework that runs a large share of FiveM roleplay servers: it manages players, jobs, money, inventory and weapons through the es_extended resource. If you write scripts for an ESX server, you talk to it through the ESX object, the xPlayer object on the server and PlayerData on the client. This page explains what the ESX skill for FiveAI covers, the mistakes that break ESX scripts most often, and how to install the skill in your AI assistant.

Quick reference

Most searched ESX Legacy calls. Server calls need a nil check on xPlayer.

Call	Side	What it does
ESX.GetPlayerFromId(source)	Server	Returns the xPlayer for a player, or nil
ESX.GetPlayerFromIdentifier(identifier)	Server	Finds a player by identifier
ESX.GetExtendedPlayers(key, value)	Server	Players matching a filter such as 'job', 'police'
xPlayer.getMoney() / addMoney(amount, reason) / removeMoney(amount, reason)	Server	Cash
xPlayer.getAccount(name) / addAccountMoney(account, amount, reason)	Server	Accounts such as bank
xPlayer.getJob() / setJob(name, grade, onDuty)	Server	Job data and job changes
xPlayer.addInventoryItem(item, count) / removeInventoryItem(item, count)	Server	Items
ESX.RegisterServerCallback(name, cb)	Server	Answer a client request; the handler gets source, cb, ...
ESX.TriggerServerCallback(name, cb, ...)	Client	Ask the server for data
ESX.IsPlayerLoaded() / ESX.PlayerData	Client	Check the player loaded before reading data

What the ESX skill gives you

The skill is a SKILL.md file with rule files for each part of the framework:

• core-concepts: how es_extended initializes, what PlayerData holds on the client and what xPlayer holds on the server.
• client-functions and server-functions: ESX.IsPlayerLoaded() and ESX.PlayerData on the client, ESX.GetPlayerFromId(source) on the server, callbacks and triggers.
• xplayer-methods: the methods for money, items, weapons, inventory, jobs and metadata.
• jobs-economy: job definitions, salaries, the money and bank accounts, society management.
• inventory-items and weapons-loadout: item registration, usable items, weight, weapons, components, ammo and tints.
• events-callbacks: ESX events, server and client callbacks, and SecureNetEvent for events that clients trigger.
• best-practices: nil checks, caching player objects, camelCase naming, few globals, and ox_lib for menus, notifications and progress bars instead of the ESX UI.

Use it when you create an ESX resource, add a job, touch the economy or write anything that reads player data.

Common mistakes with ESX

• Using xPlayer without a nil check. Symptom: "attempt to index a nil value" in the server console when a player disconnects mid-event or the source is invalid. Fix: local xPlayer = ESX.GetPlayerFromId(source) followed by if not xPlayer then return end.
• Mixing ESX and QBCore APIs. Symptom: QBCore.Functions.GetPlayer or a Player.Functions.AddMoney call inside an ESX script, and a nil error at runtime. This happens when a script was copied from a QBCore tutorial. Fix: use ESX.GetPlayerFromId and the xPlayer methods, nothing else.
• Reading ESX.PlayerData before the player is loaded. Symptom: empty job or money fields on the client during the first seconds after spawn. Fix: check ESX.IsPlayerLoaded() or wait for the player loaded event before reading PlayerData.
• Trusting money amounts from the client. Symptom: a cheater triggers your event with a custom amount and the server pays it. Fix: compute prices and rewards on the server, validate the source and use SecureNetEvent for client-triggered events.
• Calling ESX.GetPlayerFromId inside loops. Symptom: a server thread that ticks every frame and looks up the same player each iteration. Fix: get xPlayer once, keep it in a local, and reuse it.

Why AI assistants get ESX wrong

A generic assistant has seen years of ESX tutorials, and many of them target old versions. It will often reach for the esx:getSharedObject event to obtain the ESX object, invent methods that do not exist on xPlayer, or put server-only logic in a client file. It also mixes framework vocabulary: xPlayer in one function, Player.PlayerData in the next, because both appear in its training data.

The skill gives the assistant a short, current reference instead. Older tutorials use the getSharedObject event; ESX Legacy provides the object through the es_extended import or export, and the skill's core concepts file points the assistant to that. The principles list (check nil, wait for player load, never trust the client, cache player objects, prefer ox_lib for UI) is loaded every time you ask for ESX code, so the output matches the API your server runs.

To see how a skill compares with other FiveM AI setups, read our comparison.

Install the ESX skill in 30 seconds

1. Click "Download SKILL.md" at the top of this page.
2. Unzip it into your AI tool's skills or rules folder. The install section below shows the exact path for Claude Code, Cursor and VS Code.
3. Ask the assistant for something concrete, such as a server event that removes an item and adds money to the bank account, and check that it uses ESX.GetPlayerFromId with a nil check.