Scripts Written Against the xPlayer Contract
ESX has been the backbone of FiveM roleplay longer than anything else still in use, and ESX Legacy keeps it current. Everything in this collection hooks the framework properly: xPlayer for identity and money, the job and grade system for access, and societies for business accounts.
Scripts in this category
32 products
ESX in one paragraph
ESX gives every connected player an xPlayer object holding money, job, grade, inventory and metadata, and gives the server a set of events for changing it. A script that respects that contract is one your economy can trust: money added through addAccountMoney shows up everywhere, a job check against xPlayer.job.name honours the whitelist your admins actually manage, and an item added through the inventory API is a real item that can be dropped, stolen or sold.
Societies, and why they matter for job scripts
The piece newcomers miss is society accounts. ESX models a business as its own balance, whether that is the mechanic shop, the taxi company or the police department, so a job script can pay wages out of a shop's own funds instead of minting money into existence. A job script that ignores societies and pays from nowhere is an inflation machine. When you are comparing two versions of the same job, whether it supports societies is a better question than how many animations it has.
ESX Legacy versus the old branches
"ESX compatible" is not one thing. Legacy reworked how items, accounts and the inventory are addressed, and a resource written for an older branch can fail in quiet ways: money going to the wrong account, items registering but never appearing. Every product page here names the framework and dependencies it targets. If your server is on Legacy, match it. If it is on an older fork, budget time for the bridge.
Running ESX alongside QBCore-era resources
Many scripts in this store ship bridges for ESX, QBCore and Qbox in the same download, because the interaction layer of target, inventory and notifications is now largely shared. That works well for self-contained mechanics and less well for anything touching the economy, where the framework's own accounting is the whole point. Read the dependency list, add one resource per restart, and give each a full session before the next.
Frequently asked questions
Do these scripts work with ESX Legacy?
ESX Legacy is the branch this catalogue targets. Older ESX forks changed how accounts and inventory are addressed, so a resource written for Legacy may need bridging on an older fork. Each product page names the exact framework support.
What are ESX societies and do I need them?
A society is a business's own balance, such as the mechanic shop or police department as an account separate from any player. Job scripts that pay wages from a society keep money circulating instead of creating it, which is what keeps a roleplay economy from inflating. Job scripts that ignore societies pay from nowhere.
Can one script support both ESX and QBCore?
Frequently, yes. Most creators now ship framework bridges in the same download because the interaction layer is shared. It works well for self-contained mechanics; anything that touches accounting is more sensitive, so read the dependency list.
Which inventory do ESX scripts here expect?
ox_inventory is the common target on current builds, with esx_inventoryhud still in use on older servers. The two do not share an item schema, so match the dependency list on the product page to what your server runs.