ESX vs QBCore vs Qbox: Picking the Right Phone for Your Framework

A FiveM phone is only as good as its connection to your framework. Wallet transfers, company management, garages and job apps all depend on how ESX, QBCore or Qbox store money, jobs and items. This comparison explains those differences from the phone's point of view, so you know what to expect from an ESX, QBCore or Qbox phone, and where ox_core, vRP2 and standalone servers fit in.

We are not going to tell you which framework to run. If you already have one, this is about picking a phone that respects it. If you are starting fresh, the notes below show where each framework makes phone integration easier or harder.

Why the framework matters for a FiveM phone

Almost every app beyond calls and messages touches framework data:

• Wallet reads and moves cash and bank money.
• Services shows employees, toggles duty and lets bosses hire, promote and fire.
• Jobs lets players browse openings and change jobs.
• Garage and Home list vehicles and properties the player owns.
• Ride, Delivery, Rentals and Racing charge and pay out real money.
• Access rules hide apps by job, for example keeping police out of the dark web app.

A phone that talks to your framework through a thin generic layer usually gets the basics right and the edge cases wrong: offline employees, job grades, boss flags, duty state. That is why our builds ship exactly one native adapter for the framework you pick at checkout, and nothing else.

ESX phone: accounts, jobs and offline employees

ESX Legacy models a player as an xPlayer with money and named accounts. Our ESX adapter reaches es_extended through its export, so no import file or bridge is needed.

• Money: cash via xPlayer.getMoney, addMoney and removeMoney; bank via getAccount("bank") and the account money methods.
• Jobs: xPlayer.getJob() with name, grade and duty where available; job definitions and grades come from ESX.GetJobs().
• Offline employees: read from the users table, so a boss can see and manage staff who are not online.
• Company money: the Services app uses esx_addonaccount society accounts (society_<job>) for deposits and withdrawals.
• Bills: if esx_billing runs on your server, the Wallet reads and pays those bills; otherwise the phone's own billing is used.

ESX servers increasingly run ox_inventory for items, which is also the most tested inventory for the phone item. More details on the ESX phone page.

QBCore phone: PlayerData and shared jobs

QBCore keeps everything on the player object's PlayerData. That makes integration predictable.

• Money: PlayerData.money.cash and .bank, changed through Functions.AddMoney and Functions.RemoveMoney.
• Jobs: PlayerData.job with grade level, isboss and onduty; job definitions from QBCore.Shared.Jobs; changes via Functions.SetJob and SetJobDuty.
• Offline characters: read from the players table (citizenid, charinfo and job JSON) for company management.
• Company money: Renewed-Banking, qb-banking or qb-management, auto-detected.
• Items: qb-inventory and ox_inventory are the tested options; ps-inventory, qs-inventory and others have adapters that are statically verified only.

If you are replacing the bundled phone, our guide on replacing qb-phone covers the cutover in detail. Framework specifics are on the QBCore phone page.

Qbox phone: native exports, not the bridge

Qbox (qbx_core) keeps a QBCore-compatible bridge, and many resources lean on it. A phone does not need to. Our Qbox adapter calls qbx_core exports directly and only uses the qb bridge as a fallback.

• Players: exports.qbx_core:GetPlayer(source), which returns qb-shaped PlayerData, so money and job fields look familiar.
• Jobs and groups: GetJob for definitions and grades, GetGroupMembers for the employee list.
• Hiring and firing: AddPlayerToJob and RemovePlayerFromJob, which is how Qbox expects job membership to change.
• Items: first-class ox_inventory support, which Qbox servers almost always run.

The practical difference from QBCore is cleaner job management: Qbox's group model is used as intended rather than emulated. See the Qbox phone page.

ESX vs QBCore vs Qbox at a glance

• Player identity: ESX uses the xPlayer identifier; QBCore and Qbox use the citizenid.
• Money: ESX splits cash and named accounts; QBCore and Qbox store money types on PlayerData.
• Jobs: ESX has one job with a grade per player; QBCore has one job with grade, boss flag and duty; Qbox uses groups through qbx_core exports.
• Typical inventory: ox_inventory on modern ESX and Qbox, qb-inventory or ox_inventory on QBCore.
• Adapter status in our phone: ESX, QBCore and Qbox are production adapters.

For a phone, all three work well. The deciding factor is usually the rest of your resource stack, not the phone.

ox_core: groups instead of a single job (beta)

ox_core has no single "job" concept and no built-in wallet. Our ox_core adapter maps that honestly:

• The persistent charId is the owner key for data and vehicles.
• Groups act as jobs; the phone uses the first group found and resolves its grade per group.
• Cash is the money item in ox_inventory. There is no bank adapter, so phone money flows use cash.
• ox_core ships no housing system, so the Home app has nothing to list.

This adapter is beta: it follows the documented ox_core API and every call is guarded, but it is statically verified only and has not yet been tested on a live ox_core server. Test on staging first. See ox_core phone.

vRP2: classic API, synchronous calls (beta)

The vRP2 adapter uses the classic vRP2 API with synchronous return values: getUserId, getUserDataTable for identity, getMoney and tryPayment for cash, the bank money calls, and getUserGroupByType for job groups. vRPex-style async promises are not covered yet.

Like ox_core, it is beta: statically verified, not yet tested against a live vRP2 server. If a call fails, the adapter falls back to standalone behavior instead of crashing. See vRP phone.

Standalone: no framework at all

A standalone build identifies players by server ID, uses native player names, and runs every communication, media and social app without ESX or QBCore. Money is the honest limitation: with no framework, there is no money to move, so economy apps stay visible but money actions are disabled. Jobs and grades are not available either. If you later add a framework, you can configure a framework build instead. See the standalone phone page.

Inventory and voice are separate choices

Your framework does not lock your inventory or voice choice:

• Inventory is auto-detected at runtime in this order: ox_inventory, qb-inventory, qs-inventory, origen_inventory, core_inventory, codem-inventory, ps-inventory. ox_inventory and qb-inventory are tested; the other five adapters are statically verified only. In the configurator you can leave it on auto or pin ox_inventory or qb-inventory.
• Voice for calls is pma-voice, FiveM Enhanced Voice or none, on every framework. A SaltyChat adapter is included for the Radio app.

Choosing your build

1. Pick the framework you actually run. Do not pick QBCore for a Qbox server because "it is compatible"; the native adapter avoids the bridge.
2. Check which apps matter for your economy. Wallet, Garage, Home, Jobs and Services are where framework differences show up most.
3. If you are on ox_core or vRP2, budget time for testing and report any issue with a stack trace.

Installation per framework, including server.cfg order, is in how to install a FiveM phone.

Next steps

Open the configurator, choose your framework, and try the real phone in your browser before you buy. The live preview reflects the exact build you configure. Edition contents and prices are on the pricing page.