Start Here · The ecosystem map

The ox stack: ox_lib, ox_target, ox_inventory

Open almost any modern FiveM server's resource list and you will see three names again and again: ox_lib, ox_target, and ox_inventory. They show up so often that experienced developers treat them as part of the furniture. This lesson is a map, not a build. By the end you will know what each one does, why everyone uses them, and how to spot them in a script. The hands-on building with these tools lives in the paid Tracks. Here you only need to recognize the names.

You'll learn: What the three ox resources are, why almost every modern server installs them, and how to recognize them when you read a script.
Time: ~10 minutes
Difficulty: Beginner
You need: Nothing to install. This is a reading lesson. You only need to have met natives and exports in the earlier lessons.

BEFORE YOU START

What "ox" is

You already know a few of the building blocks: natives are functions the game gives you for free, and exports are functions one resource offers to another. "ox" is the next step up. It is a family of free, open, well made resources built by a community group called Overextended. Nobody at Cfx.re (the company behind FiveM) declared them official. They simply got good enough, and popular enough, that the whole community settled on them as the standard tools. When a developer says "the ox stack", they mean the cluster of Overextended resources that most servers now install before they write a single line of their own code.

The word you need for this is library. A library is a bundle of pre written code you install once and then call from your own scripts, so you do not rewrite the same thing every time. Think of it like a power tool. You do not forge your own screwdriver before hanging a shelf, you reach for one that already works. ox is a set of those tools for FiveM.

Vocabulary

library: A bundle of pre written, reusable code you install once and call from your own scripts, instead of writing that code yourself every time.
ox_lib: The Overextended helper library: ready made notifications, menus, input dialogs, progress bars, and dozens of small utilities. The base most other ox resources build on.
ox_target: The Overextended interaction system. The player looks at something in the world, an eye menu appears, and they pick an option. The modern "look at it and press a key" pattern.
ox_inventory: The Overextended inventory: a complete slot and weight item system with stacking, metadata, stashes, and shops, that other scripts plug into instead of building their own.
dependency: A resource that another resource needs in order to run. If script B uses ox_lib, then ox_lib is a dependency of B and must start first.

The three, one each

Here is each tool in one breath, with a tiny snippet so you recognize the shape when you read real code. Read these as illustrations of what a call looks like, not as something to build right now. The real building, with full explanations of every field, is in the Tracks.

ox_lib: the shared helper toolbox

ox_lib is the base. It is a grab bag of common things every script needs: pop up notifications, right click style menus, input forms, progress bars, callbacks (a way to ask the server a question and wait for the answer), and many small helpers. Instead of every developer reinventing a "show a green success toast" widget, they all call the same one from ox_lib, so the whole server looks and behaves consistently.

A notification, the single most used ox_lib call, looks like this:

lua

-- Illustration only. Shows a green pop up on the player's screen.
lib.notify({
    title = 'Shop',
    description = 'You bought bread',
    type = 'success'
})

The lib here is a global that ox_lib creates for you once it is loaded. Every ox_lib feature hangs off it: lib.notify, lib.inputDialog, lib.progressBar, and so on.

ox_target: look at something, press a key

ox_target is the interaction system you have used without knowing its name. On a modern server, you hold a key, a crosshair appears, world objects and people glow, and a little menu of options pops up: Use ATM, Open Trunk, Talk to clerk. That whole experience is ox_target. Before it existed, developers wrote fiddly "is the player within 1.5 metres and looking the right way" checks by hand for every single object. ox_target turns most of that into one small options table.

Attaching an option to a kind of object looks like this:

lua

-- Illustration only. Adds a "Use ATM" option to every ATM prop on the map.
exports.ox_target:addModel('prop_atm_01', {
    {
        name = 'use_atm',
        icon = 'fa-solid fa-credit-card',
        label = 'Use ATM',
        onSelect = function()
            -- open the ATM here
        end
    }
})

Notice this is an export call, the exact pattern you learned earlier: exports.ox_target: names the resource, then the function. That is ox_target lending your script its interaction code.

ox_inventory: a complete item system

ox_inventory is a full inventory: numbered slots, a weight limit, stacking rules, per item data like a weapon serial, plus stashes and shops. It is a big, finished system. Your own scripts do not rebuild any of it. They call into it. When your script wants to give a player five burgers, it asks ox_inventory to do it, and trusts ox_inventory as the single source of truth for what the player is carrying.

Giving an item is one export call on the server:

lua

-- Illustration only. Asks ox_inventory to give the player 5 burgers.
exports.ox_inventory:AddItem(source, 'burger', 5)

Again, an export: exports.ox_inventory:AddItem(...). Your script never touches the inventory's internal data directly. It politely asks, and ox_inventory handles the slots, the weight, and saving it all to the database.

See the pattern across all three? ox_lib hands you a lib global to call, while ox_target and ox_inventory hand you exports to call. Either way, the deal is the same one you met in the exports lesson: someone else wrote and maintains the hard code, and your script borrows it by name. That is the entire reason these libraries exist.

Why everyone uses them

Three reasons, and they stack on top of each other.

First, consistency. When every script on a server uses ox_lib for its notifications and menus, the player sees one visual style and one set of behaviours everywhere. The shop, the garage, and the job menu all feel like parts of the same game, not a patchwork stitched together by ten different developers.

Second, fewer bugs. ox_inventory has been hammered on by thousands of servers for years. Every duplication exploit and edge case has been found and fixed by the community. The inventory you would write yourself in a weekend would not survive a single determined cheater. Reusing battle tested code means inheriting all those fixes for free.

Third, and this is the big one, the ecosystem assumes them. A huge number of free and paid scripts are written to depend on ox_lib, ox_target, or ox_inventory. They will not even start without them. So once you have the ox stack installed, you unlock the ability to drop in hundreds of other people's scripts that expect it. Skip ox, and half the resources you want to use simply refuse to run.

Why is it called the de facto standard?

"De facto" means "in practice, even though no rule says so". No official authority crowned ox the standard. Cfx.re ships its own example resources, and other libraries exist. But so many developers chose ox, and so many scripts were written against it, that it became the default by sheer gravity. Qbox, one of the popular server frameworks you will meet in a later lesson, is even built to be "ox native", meaning it expects the ox stack from the start. That is what de facto standard looks like: not a law, just where everyone ended up.

You install them, scripts use them

So what is your actual job with these as a beginner? Mostly just to have them installed and started, in the right order, before the scripts that need them.

A typical server.cfg order looks like this, libraries first, your own scripts after:

text

ensure ox_lib
ensure ox_target
ensure ox_inventory
ensure my_first_script

That is the whole relationship. The libraries load, they create their lib global and publish their exports, and then your scripts call into them. You are not expected to understand every option today. You are expected to know what these three names mean when you see them.

Common beginner misconceptions

A few wrong ideas trip up almost everyone at the start. Spot them now and save yourself an evening of confusion.

Symptom	Fix
`attempt to index a nil value (global 'lib')`	Your script tried to use lib before ox_lib loaded, or ox_lib is not started at all. ox_lib must be ensured in server.cfg above any script that uses it. Load order is top to bottom, so the library has to come first.
`A script errors with "dependency ox_lib not found" or simply will not start`	ox_lib is missing or starts after the script that needs it. Install ox_lib and put its ensure line above the script. A dependency must be running before the resource that depends on it.
`Thinking ox is a framework that runs your whole server`	It is not. ox is a set of libraries, reusable tools your scripts call. A framework (Qbox, ESX, QBCore) is the bigger system that manages players, jobs, and money. You will meet frameworks in a later lesson. ox sits underneath and beside them, not in their place.
`Mixing incompatible versions, where a script expects newer ox functions than the ox_lib you installed`	Keep ox_lib, ox_target, and ox_inventory updated together from the official Overextended releases. An old library with a new script (or the reverse) causes calls to a function that does not exist yet. Match versions.

If a script says it depends on ox_lib, what must be true for it to work?

ox_lib must be installed and started before that script loads. In practice that means ox_lib has its own folder in resources, and its ensure ox_lib line sits above the script's ensure line in server.cfg, because resources load top to bottom. If ox_lib is missing or starts later, the script either refuses to start or crashes the moment it tries to use the lib global, with an error like attempt to index a nil value (global 'lib'). A dependency has to exist before the thing that depends on it can use it.

Try it yourself

TRY IT YOURSELF

No code to write here, just recognition, which is the whole skill this lesson is teaching.

You are reading a free script you downloaded. Somewhere in it, a player walks up to a vending machine, an eye menu appears over it, and they pick "Buy soda". The script's manifest lists a resource it depends on for that interaction.

Which ox resource is it most likely using for the "look at the machine and pick an option" prompt? Think it through, then check below.

Solution: ox_target. The "look at something in the world and a menu of options appears" experience is exactly what ox_target provides. ox_lib could show the notification after the purchase, and ox_inventory would actually hand over the soda, but the part where the player aims at the machine and an option pops up is ox_target. Recognizing which tool owns which job, just from the behaviour you see, is how you start reading real servers.

What you can do now

Say what "ox" is: a family of free, open, community made (Overextended) resources that became the de facto standard.
Name the three core ox resources and what each does: ox_lib (helpers, notifications, menus), ox_target (look and interact), ox_inventory (slot and weight items).
Explain why servers use them: consistent UI, fewer bugs, and a huge ecosystem of scripts that assume them.
Recognize that ox resources are dependencies you ensure first, with ox_lib before the rest.
Avoid the beginner traps: load order matters, ox is libraries not a framework, and versions must match.

You now have the map of the tools you will see everywhere. The ox stack handles your interfaces, interactions, and items, but it sits on top of one more thing almost every serious server needs: a place to store data that survives a restart. That is a database, and the resource that talks to it is oxmysql. Next up: "Databases and oxmysql".

REFERENCES

ox_lib docs ↗

FiveM docs ↗